简介：这份C#编写的接口测试工具以Windows Forms（WinForm）为图形界面，支持POST、GET、PUT、DELETE四种常见HTTP请求，适用于开发者在接口调试、联调或验收阶段快速验证请求参数、状态码与响应数据。资源为RAR压缩包，共41个文件，约62KB，内含13个C#源码文件、6个config配置、2个csproj工程文件、2个resx资源文件，以及编译生成的exe与pdb，目录结构完整，可在Visual Studio中直接打开、运行或继续扩展。代码注释清晰，覆盖了HTTP请求组装、发送和响应解析的关键环节，既可作为轻量级接口测试工具直接使用，也是学习C#网络编程和WinForm界面开发的良好参考实例。目前已有1447人学习下载，适合需要快速验证API或希望参考C# HTTP请求实现的开发者获取。
1. 接口测试工具：C# WinForms 发出的四类 HTTP 请求，真的能一屏管完么
先给结论：这工具能干的事，就是你在一个 C# 的 Windows 窗体程序里填上 URL、选好请求类型、带上参数点一下发送，然后看状态码、响应时间、头部和返回体。Postman 能做的日常验证，它都能做，而且源代码就在你手头，想改就改。适合谁呢——后端开发做完接口随手自测、测试同学在不方便装大型工具的环境下做冒烟验证、刚学 WinForms 想做完整项目练手的 A 同学。资源本身不是黑匣子：四个请求方法、请求头配置、超时设置、响应展示都在同一个工程里，逻辑直接跟着代码走就能读通。接下来这篇文章，我会从请求核心类的设计讲起，一直讲到异步 UI、排查乱码和批量回归，中间会贴可运行代码，也会把几个很容易翻车的点标出来。看完你就能判断这套代码值不值得下载，也能在半小时内跑出一个自己的版本。
2. 请求核心类：为什么用 HttpClient，而不是 HttpWebRequest
2.1 先想清楚请求层要管多少事
接口测试工具最基础的能力不是发请求，而是可控地发请求。你得能设置 URL、请求方式、Header、Body、超时时间、字符编码，还得能拿到返回来的状态码、响应头、响应体、耗时。这些事如果全部堆在主窗体的按钮事件里，代码会膨胀到没法维护。常见的做法是拆一个独立的请求核心类，把“发一次请求并带回结果”这个动作收敛成一个方法。
这个工具里请求核心类的职责划分很清晰：界面只负责收集用户输入，核心类只负责把输入转成 HttpRequestMessage 并发出去，返回一个带状态、耗时、内容、头部的结果对象。这样做的直接好处是，你后面想加批量测试、写日志、导出报告，都只要对着结果对象操作，界面层不用动。
2.2 用单个 HttpClient 实例跨请求复用是性能关键
很多初学代码的人习惯每个请求 new 一个 HttpClient，这在快速连续调用时会耗尽 Socket 端口，而且每次握手、TLS 协商的开销都重复了。HttpClient 的设计意图是长期复用：一个进程里通常只需要一个共享实例，配合 HttpClientHandler 配置代理、Cookie、证书校验策略。
在这份源码工程里，常用做法是在请求核心类里声明一个静态字段：
private static readonly HttpClient _httpClient; static RequestHelper() { var handler = new HttpClientHandler { // 自动处理响应压缩 AutomaticDecompression = System.Net.DecompressionMethods.GZip | System.Net.DecompressionMethods.Deflate, // 允许自动携带服务端返回的 Cookie UseCookies = true }; _httpClient = new HttpClient(handler) { Timeout = TimeSpan.FromSeconds(30) // 默认超时 30 秒，可按需调整 }; // 给所有请求统一加一个 UA，部分服务端没有 UA 会直接拒绝 _httpClient.DefaultRequestHeaders.UserAgent.ParseAdd("CSharpApiTester/1.0"); }这段代码的逻辑很直白：handler 管连接层面的策略，HttpClient 管 HTTP 级别的默认头、超时。AutomaticDecompression 的作用是当服务端返回 gzip 压缩内容时自动解压，很多接口返回的 JSON 是压缩过的，不设这个字段你会看到一堆乱码或解压失败。UseCookies 打开后，登录接口返回的 Cookie 会被同一个 HttpClient 自动带着走，省去手动拼接 Cookie 头的麻烦。
超时参数是最常用的调整点，如果你测的是耗时较长的批量导出接口，30 秒不够用，可以直接把 Timeout 改到 100 秒或更大。注意，这里说的超时是“单次请求从开始到拿到响应头”的耗时上限，不是整个下载大文件的耗时上限。
2.3 请求方法统一入口：减少重复代码
接下来是核心方法。四个请求方式差异主要在 Method 和 Content 上，所以一个统一入口加两个分支就能覆盖。实际操作中我把入口设计成接受一个 RequestModel 对象，里面包含 Url、Method、Headers、Body、ContentType、Params 等字段：
public static async Task<ResponseModel> SendAsync(RequestModel request) { using var httpRequest = new HttpRequestMessage { Method = new HttpMethod(request.Method.ToUpperInvariant()), RequestUri = new Uri(request.Url) }; // 添加自定义请求头 if (request.Headers != null) { foreach (var header in request.Headers) { // 部分 Header 只能用 Add，部分只能用 TryAddWithoutValidation，统一用后者更省心 httpRequest.Headers.TryAddWithoutValidation(header.Key, header.Value); } } // GET 和 DELETE 一般不携带 body，POST 和 PUT 则用 StringContent 携带 if (request.Method.Equals("POST", StringComparison.OrdinalIgnoreCase) || request.Method.Equals("PUT", StringComparison.OrdinalIgnoreCase)) { httpRequest.Content = new StringContent(request.Body ?? string.Empty, Encoding.UTF8, request.ContentType); } var stopwatch = System.Diagnostics.Stopwatch.StartNew(); try { using var response = await _httpClient.SendAsync(httpRequest); var responseModel = new ResponseModel { StatusCode = (int)response.StatusCode, ReasonPhrase = response.ReasonPhrase, ResponseTimeMs = stopwatch.ElapsedMilliseconds, Headers = string.Join(Environment.NewLine, response.Headers.Select(h => $"{h.Key}: {string.Join(", ", h.Value)}")), Body = await response.Content.ReadAsStringAsync() }; return responseModel; } catch (TaskCanceledException) { // 超时会触发 TaskCanceledException，需要跟主动取消区分开 return new ResponseModel { StatusCode = -1, Body = "请求超时，请检查服务端地址或延长超时时间" }; } }逻辑说明：HttpRequestMessage 是整条请求的载体，Method 由用户选择的 GET/POST/PUT/DELETE 字符串转换而来。请求头用 TryAddWithoutValidation 的好处是，头名大小写不规范或值里带特殊字符时不会直接抛异常，这对测试工具很重要——你要测的就是非标准请求下服务端的表现。GET 和 DELETE 不走 Content 分支，参数放在 URL 上就完成了；POST 和 PUT 用 StringContent 构造 body，同时显式传 UTF-8 编码避免中文乱码。
Stopwatch 用来记耗时，精确到毫秒，这个数据在对比不同服务端节点速度快慢时很有说服力。TaskCanceledException 是超时最常见的表现，必须捕获，否则用户看到的只是一句“任务已取消”的弹窗，根本不知道是超时还是自己点了取消。
3. 四种请求的落地：GET、POST、PUT、DELETE 的实现与差异
3.1 POST 与 PUT：body、JSON 序列化与 Content-Type 的三角关系
界面层通常用一个 ComboBox 让用户选请求方式，选中不同方式时，body 输入框的可用状态会跟着变。POST 和 PUT 的区别不是工具要管的事，工具只需要保证用户填了什么就发什么。但有一个点必须处理——JSON 字符串的验证与序列化格式。RequestBody 是从一个多行 TextBox 里读出来的字符串，用户可能手打也可能从别处粘贴。常见做法是发送前用 JSON 解析库做一次格式校验，合法才发，不合法就在界面提示。
写测试工具时会遇到一个高频问题：用户填了 JSON 但没注意 Content-Type，服务端按表单解析，一个字都读不到。所以工具里 Content-Type 不能写死，通常是默认 Json 类型，同时给 form 选项。POST 和 PUT 发送 body 时，StringContent 的第三个参数就是 Content-Type，如 application/json。手动填 set-body 时，常见处理是发送前用 JSON 解析库做一次格式校验，合法才发，不合法就在界面提示。
3.2 GET 与 DELETE：URL 拼接参数与无 body 场景
GET 是最常用的，参数有两种放法：直接拼在 URL 的 ? 后面，或者放在键值对列表里由工具拼接。后一种对用户更友好，因为不用手动处理 & 符号和中文编码。下面这段代码负责把键值对参数拼到 URL 上：
public static string BuildUrlWithParams(string baseUrl, Dictionary<string, string> paramsDict) { if (paramsDict == null || paramsDict.Count == 0) return baseUrl; // 先判断原 URL 是不是已经带了 ?，避免拼出两个问号 var separator = baseUrl.Contains("?") ? "&" : "?"; var pairs = paramsDict.Select(kv => $"{Uri.EscapeDataString(kv.Key)}={Uri.EscapeDataString(kv.Value)}"); return baseUrl + separator + string.Join("&", pairs); }这段代码解决的问题很具体：用户输入了“名称”作为参数名、“张三”作为参数值，直接拼接会得到带中文的 URL，很多服务端会报 400。Uri.EscapeDataString 会把中文转成 %E5%BC%A0%E4%B8%89 这种安全形式，& 和 = 也被正确转义。separator 那句是防止用户原始 URL 已带 ? 时拼出错误的地址。
DELETE 请求在不同服务端框架里的行为差异很大：有的接受 body，有的直接忽略 body，有的没有 body 就算非法。因此工具的设计是 DELETE 请求默认不提供 body 输入框，参数全部走 URL。如果你测的服务端需要 DELETE body（比如一些云厂商的对象存储接口），可以在工具里加一个开关：需要时把 DELETE 归入带 body 分支，但不要默认开启，否则大多数测不透的业务接口都会被奇怪的 body 干扰。
3.3 响应展示：状态码、耗时、Headers、Body 格式化
请求发出去了，响应展示决定了这个工具好不好用。初版实现往往只是把响应字符串塞进一个 TextBox，接口返回的压缩内容、带缩进的 JSON、多行字符串看起来就是一团乱麻。这里我习惯分四个区块展示：
- 状态码与耗时，放在一个单独的文本标签里，状态码不是 2xx 就用红色显示；
- 响应头，按“键: 值”的格式换行排列，方便查看 Set-Cookie、Server、Content-Type；
- 响应体，默认展示原文，如果检测到 JSON 则尝试格式化缩进；
- 请求日志，追加每条请求的完整信息，方便对比多轮调用。
响应体格式化代码可以这样写：
public static string FormatResponseBody(string rawBody) { if (string.IsNullOrWhiteSpace(rawBody)) return rawBody; // 先判断是否 JSON；如果是 JSON 才格式化，否则保持原样 if (rawBody.TrimStart().StartsWith("{") || rawBody.TrimStart().StartsWith("[")) { try { var json = System.Text.Json.JsonDocument.Parse(rawBody); var formatted = System.Text.Json.JsonSerializer.Serialize(json.RootElement, new System.Text.Json.JsonSerializerOptions { WriteIndented = true }); return formatted; } catch (System.Text.Json.JsonException) { // 解析失败就返回原文，避免把非 JSON 内容强制格式化 return rawBody; } } return rawBody; }这段代码规避了一个常见问题：不少测试工具看到“长得像 JSON”的字符串直接格式化，结果遇到纯文本或 XML 时报了一堆错。这里先看第一个非空字符是 { 还是 [，再尝试用 System.Text.Json 解析。解析失败说明它是伪 JSON，返回原文。WriteIndented 设为 true 时缩进为两空格，配合 TextBox 的等宽字体，看起来比压缩成一行舒服得多。
头部信息不单列出来还有个坏处：有的接口返回的 JSON 里带错误码，但 HTTP 状态码是 200，业务异常和网络异常混在一起容易误判。把状态码、耗时、Headers 分开展示后，一眼就能分辨是网络链路问题还是业务逻辑问题。
4. 界面层交互：异步不卡顿与请求日志、历史记录
4.1 同步请求为什么卡死 WinForms 界面
WinForms 的 UI 跑在主线程上，按钮点击事件也是主线程执行。如果你在事件处理方法里直接调用 _httpClient.SendAsync(...).Result 或直接同步调用 .Send(...)，主线程会被网络 I/O 阻塞，窗口在这段时间内无法移动、无法重绘，最直观的表现就是“窗口白了，转圈圈转半天，点关闭都没用”。这是因为 HttpWebRequest 的同步方法在等待网络数据时，底层会占用线程资源。
很多新手第一次跑这个工具时，点发送后整个窗口卡住几十秒，以为程序死了，其实请求还在进行中。这类体验放在接口调试场景里非常伤——用户想多开几个窗口同时对比接口环境，结果每个窗口都只能排队，效率极低。
4.2 async/await 的正确落地：把 UI 线程让出去
这一版工具的做法是在异步方法里用 async/await，而不是通过启用 BackgroundWorker 或开 Thread。async/await 的核心收益是：异步方法中 await 之后的那段代码，默认会回到 SynchronizationContext 上执行，而 WinForms 的 SynchronizationContext 就是主 UI 线程。也就是说，await 等待网络的同时界面保持响应，响应拿到后又能直接安全地更新控件值，不需要手动 Invoke。
private async void BtnSend_Click(object sender, EventArgs e) { // 1. 从界面读取参数 var request = new RequestModel { Url = TxtUrl.Text.Trim(), Method = CboMethod.SelectedItem.ToString(), ContentType = CboContentType.SelectedItem.ToString(), Body = TxtBody.Text, Headers = ParseHeaders(TxtHeaders.Lines) }; // 2. 发送前清空上一次响应，避免新旧内容混淆 TxtResponse.Clear(); BtnSend.Enabled = false; // 3. await 等待期间 UI 不卡 var response = await RequestHelper.SendAsync(request); // 4. 回到主线程后更新界面 TxtResponse.Text = FormatResponseBody(response.Body); LblStatus.Text = $"{response.StatusCode} {response.ReasonPhrase}，耗时 {response.ResponseTimeMs} ms"; if (response.StatusCode >= 400) LblStatus.ForeColor = Color.Red; else LblStatus.ForeColor = Color.Green; // 5. 记录日志 LogRequest(request, response); BtnSend.Enabled = true; }async void 用在事件处理中是合理特例，它允许事件处理器以异步方式触发，而不需要返回值。整个方法的关键在第三步：await 让出 CPU 控制权，消息泵继续跑，用户依然能拖动窗口、点击其他按钮；请求完成后再自动回到主线程更新界面。如果误把 await 写成了 .Result，主线程照样卡死，所以代码规范上我会在请求核心类的 SendAsync 方法后强制要求调用方配合 await。
这五步顺序是有讲究的：清空上次响应是为了避免用户看着旧内容误判新结果；禁用发送按钮是防止用户在请求进行中连续点击，产生重复请求；最终恢复按钮放在日志记录之后，保证日志写完才允许下一条。
4.3 日志区与历史流量：单机小工具也要留痕
没写过测试工具的人容易忽略日志区。真实场景里，你发了一串请求，其中一次返回 500，排查时你最好能看见这次请求的完整 URL、请求头和请求体。把日志追加到界面的一个只读多行文本区域，或者记录到本地文本文件里，都能帮大忙。这份工程里比较实用的方案是：界面底部加一个只读 TextBox 作为日志区，每次请求完成后把方法、URL、耗时、状态码拼成一行追加进去；同时如果开启“文件日志”，则按天写入 Logs 目录下的 txt 文件。
日志文件按天切分是这是我个人踩过的坑：如果不切分，一个长期使用的测试工具会攒出几百 MB 的日志，临时要翻一天前的请求记录，编辑器打开都卡。核心代码就一行：
public static void AppendLog(string logContent, string logDir = "Logs") { var day = DateTime.Now.ToString("yyyyMMdd"); Directory.CreateDirectory(logDir); File.AppendAllText(Path.Combine(logDir, $"api_{day}.log"), $"[{DateTime.Now:HH:mm:ss}] {logContent}{Environment.NewLine}", Encoding.UTF8); }传入的 logContent 是发送方组装好的完整语句，比如“POST https://example.com/api/order status=200 time=123ms”。文件编码固定为 UTF-8，是因为默认的 ANSI 编码在不同系统区域设置下写出的中文日志，换台电脑就会乱。
日志代码放在界面事件处理器而不是请求核心类里，这背后有个设计取舍：核心类只管通信，日志属于界面策略。当你后面想把它做成无界面的命令行工具时，核心类不需要改，日志逻辑跟着界面方案走就行；反过来，如果日志写在核心类里，核心类就被 UI 细节污染了，复用性变差。
5. 避坑清单：C# 接口测试工具中最常见的五个翻车点
5.1 界面假死，点发送后窗口完全无响应
现象：点击发送按钮后，窗体变白、标题栏出现“未响应”，任何操作都延迟很久。
原因：绝大多数情况是同步调用 HttpClient 或 HttpWebRequest 的请求阻塞了 UI 线程。具体表现为用了 _httpClient.SendAsync(...).Result、.Wait()，或者用了老式 WebClient 的同步方法。
解决：把事件处理器改成 async void，并且从 UI 到请求全链路使用 await。如果看到代码里有 .Result 或 .Wait()，立即替换成 await。注意不要在 async 方法里用 Task.Run 去包一层线程，这样既浪费资源，又容易在 UI 更新时需要手动处理跨线程抛出的异常。
5.2 返回的中文全部变成问号或乱码
现象：同样是 GET 请求，浏览器访问正常，工具里返回的中文显示成“??”或成段的 锟斤拷 乱码。
原因：响应内容在多个环节发生了编码错位。第一是请求发出时没指定 Accept-Charset，服务端返回了 UTF-8 内容但工具按默认编码解析；第二是 Response Content-Type 里没带 charset，工具读不到字符集信息，就用系统默认的 GBK 去解码。
解决：读取响应体时按 UTF-8 显式解码，不要用 ReadAsStringAsync 的默认逻辑盲信响应头。在请求头里主动加入 Accept-Charset: UTF-8，并且把 HttpClient 内部读取字符流时的编码策略统一为 UTF-8。如果服务端确实返回 GBK 编码内容，那需要在响应头无法给出 charset 的情况下做一次重试解码，核心代码是 Encoding.GetEncoding("GBK").GetString(bytes)。
扩展一下：如果用了 AutomaticDecompression 却没设置正确的字符集，解压后的字节流仍是 UTF-8，但系统继续按 GBK 解码，就会出现“解压后比乱码更乱”的奇观。检查顺序是：先确认解压是否生效，再确认字符集，不要一口气改两个变量。
5.3 DELETE 请求带 body 被服务端吞掉
现象：工具里写了 DELETE body，服务端接口收到的是空 body；或者在 Fiddler 里能看到 body 确实发出去，但业务代码读不到任何内容。
原因：部分服务端框架和网关对 DELETE 请求的 body 支持不完整，或者中间代理层直接把请求体截断。这不是工具本身的问题，而是 HTTP 语义在链路上的实现差异。
解决：先用命令行工具和浏览器开发者工具确认服务端到底能不能接收 DELETE body。如果服务端框架是某些老版本 WebAPI 或云网关，稳妥的方案是改成 POST 请求并在 URL 或自定义 Header 里带操作标识；或者把参数全部放到 URL query 上。在这份工具里我会加一个“发送 DELETE body”的复选框，默认关，遇到特殊服务端再手动开，而不是删除代码分支。
5.4 返回 HTTP 500 但工具提示请求成功
现象：状态码显示为 200，但返回体里是业务错误信息；或者响应时间极短，看起来像服务端直接拒绝但没走 HTTP 错误码。
原因：这是“HTTP 状态码与业务状态码分离”的正常现象。很多系统的设计是 HTTP 层面一律返回 200，业务成功与否看响应 JSON 里的 success 或 code 字段。如果工具只按状态码判断成功失败，UI 就会误报。
解决：在工具里加一个状态码区间与业务状态码的联动显示。响应体是 JSON 时，用刚才那个 JSON 解析逻辑提取 code/success/msg 字段，额外显示在状态文本里。至于把哪种业务状态当作“失败”，要给用户留设置项，因为不同团队的字段名可能是 ret、status、code、errcode，写死任何一幕都会让另一部分项目没法用。
5.5 每次请求都 new 一个 HttpClient，压测时端口耗尽
现象：批量测试时跑了几百个请求，程序开始卡，后面依次报 SocketException: Only one usage of each socket address；任务管理器里看到大量 TIME_WAIT 状态。
原因：HttpClient 内部维持着连接池，频繁 new 会让连接池永远建不起来，每个请求都走一次完整的 TCP 握手和 TLS 握手，旧的连接进入 TIME_WAIT 后进一步占满端口。
解决：不管请求多少，都保持全局唯一 HttpClient 实例。真的需要不同 BaseAddress、不同超时时间，也只需要多声明两个具名 HttpClient，而不是每次 new。顺带一提，HttpClient 被设计成长期存活的对象后，它的 DNS 解析行为默认不刷新，如果测试时频繁切换域名或 VIP，可以设置 HttpClientHandler.PooledConnectionLifetime 来控制连接复用时间，但这不是最先要做的事。
6. 进阶：把工具从“单次请求”升级成“批量回归脚本”
6.1 用例文件格式与导入
手工测试的场景总有尽头：当接口参数有十几种组合、又要验证不同返回值时，一条一条在界面上手填效率太低。这个工具可以加一个导入功能，让用户准备一个 JSON 文件描述多组请求用例：
[ { "name": "正常订单查询", "method": "GET", "url": "https://example.com/api/order/1001", "headers": { "Authorization": "Bearer test-token" } }, { "name": "非法订单号", "method": "GET", "url": "https://example.com/api/order/abc" } ]导入时用 StreamReader 读文件，JsonDocument.Parse 后逐条转成 RequestModel，在 DataGridView 里罗列出来。这样做的好处是：用例可以进版本管理，换同事接手时不用口口相传“你帮我测一下那个订单接口”。
6.2 批量执行与统计
执行阶段，遍历 DataGridView 里的用例，每条都走同一个 RequestHelper.SendAsync，但要注意控制并发。小规模用例我用 await Task.WhenAll 一把梭，超过 50 条就改成信号量限流，一次最多放行 5 个请求，避免瞬间把服务端打满。结果统计用四列展示：用例名、状态码、耗时、通过与否。总的通过率、平均耗时、P95 耗时就地算出并显示在底部状态栏。
6.3 从批量回归收到的一个硬教训
批量回归上线之后的一次真实翻车，让我改了一个习惯：当时统计结果里显示全部通过，但研发复核时发现一半请求打到了测试环境，因为用例文件里的域名统一写成了测试域名，而线上环境的返回体和超时行为跟测试环境差异很大，导致一批本会失败的用例在测试环境全部“通过”。从那以后我每次批量执行前强制走一遍“环境确认”：把用例文件的域名、环境标识、账号信息导出一个摘要，肉眼过完再执行。
顺带一提，批量回归的结果我也习惯写到一个 CSV 文件里，字段：时间戳、用例名、URL、状态码、耗时、响应体前 200 字符。后续排查线上问题时能回看“那会儿这个接口到底返回了什么”。
接口测试工具做到这一步，已经不是个玩具了——你能把它用在接口变更后的冒烟回归上，也能用它记录一段时间的接口健康状态。希望这份源码和这些处理习惯能帮到你，节省一点排查问题的时间。
本文还有配套的精品资源，点击获取
