简介这是一份面向.NET桌面开发者的Winform网络通信示例聚焦于通过HTTP POST提交JSON数据并接收服务器返回结果这一常见需求适合已掌握C#基础、希望理解桌面端接口调用与异步处理的学习者参考。压缩包共34个文件约59KB以13个cs源码和resx窗体资源为主辅以config配置、sln/csproj工程文件及exe、pdb等编译输出工程结构较完整。已有3385人学习下载说明该主题在实际开发中具有较高关注度。包内示例围绕HttpClient发起异步POST请求展开演示Json.NET序列化对象、以application/json构造StringContent、读取响应内容以及根据状态码处理成功与错误分支并包含窗体交互与HTTP封装代码便于读者对照理解调用关系和调试思路。对于需要进一步处理认证、超时控制等情况的桌面应用也可将其作为基础骨架参考。1. 从一次 400 说起Winform 里 POST JSON 到底卡在哪某开发者做了个桌面小工具用 Winform 填几个参数点按钮把数据推到对方接口结果服务端只回了一个 400没有堆栈、没有提示连哪一行出错都不知道。这类场景里HTTP POST 提交 JSON 并不是「拼个字符串发出去」这么简单它由三块拼起来一份能被服务端正确解析的 JSON 文本、一个明确声明了Content-Type的请求体、一条能把响应读回来并还原成对象的链路。任何一块掉链子报错都会指向别的地方排查方向直接跑偏。这份资源就是一个能直接跑起来的 Winform 窗体程序输入框填参数、按钮发请求、表格显示返回结果把整条链路做成了一个看得见摸得着的样例。它适合要对接第三方 HTTP 接口、又不想每次从零写一遍请求层的桌面端开发者也适合刚接触async/await想在 Winform 里练手的人。2. 拆开一次请求HttpClient 与 StringContent 的最小闭环2.1 为什么不再用 WebClient 和 HttpWebRequest打开老项目请求层大概率长这样WebClient的UploadString一把梭或者HttpWebRequest里手工拼ContentLength、GetRequestStream、Write、GetResponse最后还要记得Close。这套写法在 .NET Framework 4.x 上能跑但问题很集中。WebClient的错误信息粒度粗服务端返回 400 时它只抛一个WebException响应体藏在ex.Response里得强转成HttpWebResponse再读一次流才能看到服务端到底说了什么。HttpWebRequest更啰嗦每个环节都要自己管using漏一个就是连接泄漏。HttpClient是后来统一出来的门面把方法、Header、内容、超时、取消都收进了一个类型里而且天然配合async/await。在 Winform 里这一点很关键同步发请求会卡住 UI 线程窗口变白、按钮点不动用户以为程序崩了。HttpClient的PostAsync是异步的配合await就能把等待过程交给线程池界面照常响应。代价是它有个坑必须提前说清楚HttpClient要复用不要每次请求都new一个。频繁创建会不断开新连接短时间高频调用会把本机的可用端口耗掉表现为请求越来越慢、最后直接抛连接异常。常见做法是声明一个static readonly实例全程序共用。提示静态单例在 .NET Framework 下不会自动刷新 DNS 解析结果。如果目标地址是多台机器轮换、或者做过切换程序长时间运行后可能连到旧地址。桌面工具通常跑几小时就关了影响不大真要长时间挂着可以按固定间隔重建实例或者在配置里改成固定 IP。2.2 一次完整的 POST从拼请求到读回响应先看能跑通的最小闭环。把它放在一个单独的ApiClient静态类里界面层只负责收集参数和展示结果两边职责分开后面换成别的接口也不用动窗体代码。using System; using System.Net.Http; using System.Net.Http.Headers; using System.Text; using System.Threading; using System.Threading.Tasks; public static class ApiClient { // 全局复用一个实例避免端口耗尽 private static readonly HttpClient Http CreateClient(); private static HttpClient CreateClient() { var client new HttpClient { // 整体超时包含连接、发送、读取响应全过程 Timeout TimeSpan.FromSeconds(15) }; // 声明我只接受 JSON服务端可以据此决定返回格式 client.DefaultRequestHeaders.Accept.Add( new MediaTypeWithQualityHeaderValue(application/json)); // 有些网关会校验这个头缺了直接 403 client.DefaultRequestHeaders.Add(X-Client, winform-demo/1.0); return client; } /// summary /// 提交 JSON 并返回原始响应字符串 /// /summary public static async Taskstring PostJsonAsync( string url, string jsonBody, CancellationToken token) { // 第二个参数是编码第三个参数是 Content-Type using (var content new StringContent(jsonBody, Encoding.UTF8, application/json)) using (var resp await Http.PostAsync(url, content, token).ConfigureAwait(false)) { // 先把 body 读出来无论成功失败服务端往往把原因写在里面 string text await resp.Content.ReadAsStringAsync().ConfigureAwait(false); if (!resp.IsSuccessStatusCode) { throw new HttpRequestException( $HTTP {(int)resp.StatusCode} {resp.ReasonPhrase}响应{text}); } return text; } } }这段代码有几处是刻意这么写的。StringContent的第二个参数Encoding.UTF8决定了请求体的字节编码第三个参数application/json决定了Content-Type头。很多人只传第一个参数构造函数会默认给出text/plain服务端框架一看类型不对直接回 415而错误信息往往只有一行很容易误判成 URL 写错了。ConfigureAwait(false)的作用是不强制回到 UI 线程上下文。ApiClient是底层方法它不需要碰任何控件加上这个可以少一次线程调度而窗体里的调用方await之后仍然会回到 UI 线程这个差异在第 4 章展开。ReadAsStringAsync在读之前不看状态码这是故意的。接口返回 400 或 500 时响应体里通常带着业务错误码和原因把这些内容拼进异常信息比只看到「远程服务器返回错误 (400)」有用得多。等你真的遇到一个只说 400 不说原因的接口就会明白这一行的价值。2.3 四个必调参数超时、Header、编码、Body 形态请求能发出去只是起点参数没拧对接到的就是各种莫名其妙的错误码。下面这几个是实际项目里一定会动到的。参数常见取值作用与踩点HttpClient.Timeout1030 秒覆盖连接、发送、读响应全过程。设太短会在大响应体上误判超时设太长会让界面等太久Content-Typeapplication/json不带charset时服务端多数按 UTF-8 处理但有些老框架默认 GBK中文就成了问号Acceptapplication/json影响服务端返回格式缺失时某些网关返回 HTML 错误页反序列化直接崩AuthorizationBearer xxx走令牌的接口必备注意别把令牌打在 URL 查询串里会被日志记下来Timeout设 15 秒是个折中。对接内网接口时 5 秒就够跨网络调外部服务建议放到 2030 秒因为Timeout是整个过程的总额不是空闲时间——服务端慢慢吐一个大列表中间一直有数据但总时长超了一样会被判超时。Content-Type里的charset值得单独说一句。StringContent用Encoding.UTF8构造时生成的头部是application/json; charsetutf-8这是最省事的写法。如果你手工拼 Header写成new MediaTypeHeaderValue(application/json)再赋给content.Headers.ContentTypecharset就没了个别服务端会把请求体按系统默认编码解中文参数直接变乱码日志里看着像「参数传错了」实际是编码没对齐。请求体的形态也得跟服务端约定一致。有的是裸对象{orderNo:A001}有的是包一层{data:{...},sign:...}还有的要求数组顶层是[]而不是{}。这些东西在联调前一定要拿到对方的接口文档或者抓一个能通的样例光靠猜会浪费大量时间在 400 上。3. JSON 侧的两套方案Newtonsoft.Json 与 System.Text.Json 怎么选3.1 请求模型的字段约定大小写、日期、可空值请求体不是拼字符串得先有类型。定义一个普通类字段名跟接口文档对齐是最省心的做法。麻烦出在三个地方命名风格、日期格式、可空字段。命名风格上C# 属性习惯用PascalCase接口大多要camelCase也就是OrderNo要发成orderNo。两种做法一是给每个属性打标注明确指定 JSON 名二是配全局策略让序列化器自动转。前者显式、可控属性多的时候啰嗦后者省事但遇到个别字段要特殊处理时容易漏。我一般对字段少的接口用标注字段多且风格统一的用全局策略。日期是第二个雷区。C# 的DateTime序列化默认会带时区和毫秒形如2024-05-01T00:00:0008:00而不少服务端只认yyyy-MM-dd HH:mm:ss。这种问题在本地测试时不一定暴露因为服务端可能做了宽松解析一上线换成严格解析的网关就全挂了。可空值也容易出事。int?为null时有的序列化器输出pageIndex: null服务端拿到 null 去做加法直接抛异常。要么在模型里给默认值要么让序列化器忽略 null 字段具体看接口文档怎么约定。using Newtonsoft.Json; public sealed class OrderQueryRequest { [JsonProperty(orderNo)] public string OrderNo { get; set; } [JsonProperty(beginTime)] public DateTime BeginTime { get; set; } [JsonProperty(pageIndex)] public int PageIndex { get; set; } 1; [JsonProperty(pageSize)] public int PageSize { get; set; } 20; // 可空字段为 null 时不参与序列化 [JsonProperty(status, NullValueHandling NullValueHandling.Ignore)] public int? Status { get; set; } }JsonProperty里写的是最终发出去的键名模型属性名怎么改都不影响协议。NullValueHandling.Ignore打在单个属性上只对这个字段生效比全局忽略 null 更安全——全局忽略有时会把服务端明确要求传null的字段也吃掉导致语义变化。3.2 发送端序列化两套库的写法与差异生态里主流就两套Newtonsoft.Json包名Newtonsoft.Json习惯叫 Json.NET和System.Text.Json。前者出现得早、兼容性好.NET Framework 4.x 项目基本都用它后者是官方后来做的性能更好但在老框架上要通过 NuGet 引入且默认行为更严格。序列化一行代码就够差别在配置。// 方案一Newtonsoft.Json string json1 JsonConvert.SerializeObject(payload, new JsonSerializerSettings { DateFormatString yyyy-MM-dd HH:mm:ss, // 统一日期格式 NullValueHandling NullValueHandling.Ignore, // 忽略 null 字段 Formatting Formatting.None // 不要缩进减小体积 }); // 方案二System.Text.Json var options new System.Text.Json.JsonSerializerOptions { PropertyNamingPolicy System.Text.Json.JsonNamingPolicy.CamelCase, // 自动转小写驼峰 DefaultIgnoreCondition System.Text.Json.Serialization.JsonIgnoreCondition.WhenWritingNull, Encoder System.Text.Encodings.Web.JavaScriptEncoder.UnsafeRelaxedJsonEscaping // 中文不转 \uXXXX }; string json2 System.Text.Json.JsonSerializer.Serialize(payload, options);DateFormatString只影响DateTime类型的输出字符串字段不受影响。Formatting.None是默认值显式写出来是为了提醒自己别开Indented——缩进后的 JSON 多了大量换行和空格在几十 KB 的请求体上就是白白多传几 KB日志里也不好看。System.Text.Json的UnsafeRelaxedJsonEscaping那个编码器要特别留意。默认编码器会把中文转成\u4e2d\u6587这种转义形式功能上没错服务端反序列化后还是原字符但抓包和看日志时完全没法读。名字里带Unsafe是因为它不再转义 HTML 敏感字符对纯接口调用场景没问题但如果你要把这段 JSON 直接塞进网页里渲染就得换回默认编码器。两套库的另一个差异是属性名大小写匹配。System.Text.Json默认区分大小写服务端返回{code:0}而模型属性叫Code时会静默反序列化成默认值也就是 0——正好和成功码撞上于是「明明失败了却当成成功」。Newtonsoft.Json默认不区分所以从前者换到后者时这个问题会突然冒出来。3.3 接收端反序列化错误包、缺字段、类型漂移返回结果的解析比发送更容易翻车因为服务端的实际返回经常和文档不一致。最常见的结构是统一包一层code、message、data。但data的类型会随接口变化有的是对象有的是数组有的是null。用泛型能把这个结构写一次到处用。public sealed class ApiResultT { [JsonProperty(code)] public int Code { get; set; } [JsonProperty(message)] public string Message { get; set; } [JsonProperty(data)] public T Data { get; set; } [JsonIgnore] public bool Ok Code 0; } // 调用侧 var result JsonConvert.DeserializeObjectApiResultOrderPage(text); if (result null) throw new InvalidOperationException(响应为空无法解析); if (!result.Ok) throw new InvalidOperationException($业务失败[{result.Code}]{result.Message}); dataGrid.DataSource result.Data?.Items;JsonIgnore让Ok这个计算属性不参与双向序列化否则请求包里会多一个ok: true有的服务端会因为未知字段直接拒绝。dataGrid.DataSource那一行用了空条件运算符是因为业务失败时Data通常是null直接赋给控件也不会崩但列表会显示上一次的数据看起来像「成功了但数据没变」很迷惑。类型漂移是另一个高频问题。文档写pageSize是数字实际返回20字符串文档写id是整数某条数据里是A-1001。Newtonsoft.Json对数字和字符串之间的转换有一定容忍多数情况能自动转System.Text.Json默认更严格会直接抛JsonException。这时候要么在模型里把类型放宽成string再自己转要么给System.Text.Json配一个JsonNumberHandling.AllowReadingFromString。还有一种情况是返回的根本不是 JSON。网关限流、鉴权失败、路径写错时很多服务端回的是 HTML 错误页DeserializeObject会在第一个字符处抛异常异常信息是「Unexpected character encountered」。看到这个提示第一反应应该是去打印原始响应文本而不是怀疑模型类写错了。4. 把返回结果接回界面异步回调、Invoke 与进度反馈4.1 await 之后界面为什么没回来同步上下文与 ConfigureAwaitWinform 的事件处理方法跑在 UI 线程上UI 线程上装了一个WindowsFormsSynchronizationContext。当你在事件处理方法里写await编译器会把后面的代码打包成续体continuation默认情况下这个续体会被投回原来的同步上下文也就是 UI 线程。所以下面这段代码可以放心直接操作控件private async void btnQuery_Click(object sender, EventArgs e) { string json JsonConvert.SerializeObject(new OrderQueryRequest { OrderNo txtOrderNo.Text.Trim() }); // await 之后仍然在 UI 线程可以直接改控件 string text await ApiClient.PostJsonAsync(url, json, CancellationToken.None); lblStatus.Text 已返回 text.Length 字节; }注意ApiClient内部用了ConfigureAwait(false)但外层的await没有两者互不影响。ConfigureAwait(false)只作用于它所在的那个await决定那一段续体要不要回 UI 线程。底层类不需要碰控件关掉上下文切换能省一次线程调度界面层需要碰控件保持默认续体就会回到 UI 线程。反过来说如果你在界面层也写了ConfigureAwait(false)后面的代码就跑到线程池线程上了这时去改lblStatus.Text会抛跨线程异常。这个异常在调试器里抛得很干脆一旦 release 模式或者异常被吞掉表现就是「界面偶尔不更新」非常难查。async void只应该出现在事件处理器上。其他地方一律用async Task因为async void的异常无法被调用方捕获会直接抛到同步上下文轻则弹一个未处理异常框重则进程退出。4.2 取消与超时CancellationTokenSource 的两种接法HttpClient.Timeout是个粗粒度的总闸CancellationToken是细粒度的开关。两种都要有超时防服务端不响应取消让用户能主动中止。private CancellationTokenSource _cts; private async void btnQuery_Click(object sender, EventArgs e) { if (_cts ! null) return; // 防重入见 4.3 _cts new CancellationTokenSource(TimeSpan.FromSeconds(20)); // 兜底超时 btnQuery.Enabled false; btnCancel.Enabled true; lblStatus.Text 请求中…; try { string text await ApiClient.PostJsonAsync(url, json, _cts.Token); var result JsonConvert.DeserializeObjectApiResultOrderPage(text); BindGrid(result); lblStatus.Text 完成共 (result.Data?.Items?.Count ?? 0) 条; } catch (OperationCanceledException) when (_cts.IsCancellationRequested) { // 分不清是用户点取消还是超时统一按中止处理 lblStatus.Text 请求已取消或超时; } catch (HttpRequestException ex) { lblStatus.Text 接口返回异常 ex.Message; } catch (Exception ex) { lblStatus.Text 处理失败 ex.Message; } finally { _cts.Dispose(); _cts null; btnQuery.Enabled true; btnCancel.Enabled false; } } private void btnCancel_Click(object sender, EventArgs e) { _cts?.Cancel(); // 触发上面的 OperationCanceledException }这里有个容易搞混的点HttpClient超时抛出的异常类型在 .NET Framework 上是TaskCanceledException继承自OperationCanceledException在 .NET 5 之后也还是TaskCanceledException但内部会包一个TimeoutException。为了让两个版本都能正确捕获统一写成catch (OperationCanceledException)最省事。when (_cts.IsCancellationRequested)这个异常过滤器值得保留。它能区分「主动取消或超时」和「其他原因导致的取消异常」。如果业务上需要精确区分可以给CancellationTokenSource配一个定时器、在超时触发时打一个标记或者干脆用Task.WhenAny加Task.Delay自己实现超时判断这样能明确知道是哪个分支。CancellationTokenSource一定要Dispose因为它内部挂了一个定时器。在按钮点击里频繁创建又不释放长时间的批量操作会让定时器越积越多。4.3 结果落地进度、日志、按钮防重入网络请求的耗时是不可预测的界面必须给出反馈否则用户会连点。上面代码里用_cts ! null做防重入又在finally里复位配合按钮的Enabled状态能挡住绝大多数重复提交。进度提示有两个层次。简单的是改状态栏文字lblStatus.Text 请求中…就够了。如果你用的是ProgressBar要注意HttpClient默认的PostAsync不暴露上传进度需要换成SendAsync用StreamContent自己包一层才能拿到字节级别的进度。绝大多数表单类接口的请求体只有几 KB上传进度意义不大显示一个不确定态的滚动条更合适。日志这块建议在请求层直接落盘而不是在界面层写日志。原因很简单异常发生时你往往已经切走了界面事后只记得「报了个错」。把 URL、请求体、状态码、响应体、耗时一起写进本地文件排查时不用复现。private static void LogRequest(string url, string body, int status, string resp, long ms) { string line ${DateTime.Now:yyyy-MM-dd HH:mm:ss.fff}\t{status}\t{ms}ms\t{url}\t $REQ{Truncate(body, 2000)}\tRESP{Truncate(resp, 4000)}; // 追加写入按天分文件避免单个文件过大 File.AppendAllText( Path.Combine(AppDomain.CurrentDomain.BaseDirectory, $api-{DateTime.Now:yyyyMMdd}.log), line Environment.NewLine, Encoding.UTF8); }Truncate是个自定义方法超过长度就截断并加省略号。响应体有时是几十 KB 的列表全量写盘会让日志文件迅速膨胀2000 / 4000 字符这个量级足够看出错误原因又不会失控。日志里如果包含手机号、证件号之类的敏感字段还得做脱敏这个在落盘前就该处理掉。注意日志里别记录完整的令牌和密码字段。即便是本地文件桌面上随手一个截图、一次打包发同事泄露的成本很低。5. 避坑清单五个把请求打回原形的现场5.1 返回 415请求头看着对服务端还是不认现象本地用 Postman 调同一个接口能通换成程序就是 415 Unsupported Media Type请求体内容一字不差。原因多数情况是用错了StringContent的构造重载。只传new StringContent(json)时默认Content-Type是text/plain服务端按内容协商规则拒绝。另一种情况是自定义了 Headers 但顺序写错content.Headers.ContentType被后面的赋值覆盖成了空值。解决统一用new StringContent(json, Encoding.UTF8, application/json)这个三参数重载别手工拼。代码里加一行Debug.WriteLine(content.Headers.ContentType)打出来看看比猜快得多。如果用了MultipartFormDataContent又想让某一项是 JSON那个部分的Content-Type要单独设不是整体设。5.2 400 说 JSON 解析失败肉眼却看不出问题现象接口回 400提示「JSON 格式错误」或者「Unexpected token」把请求体复制出来粘到在线格式化工具里格式完全正确。原因最常见的是请求体开头带了一个不可见的 BOM\uFEFF。从文件读取、从StringBuilder拼接、或者从剪贴板复制时都可能带上。服务端的 JSON 解析器看到第一个字符不是{或[直接报错。第二种情况是中文被转成了\uXXXX之外的乱码比如用 GBK 编码发出去服务端按 UTF-8 解。解决发送前对字符串做一次清洗json.Trim().TrimStart(\uFEFF)。编码一律用Encoding.UTF8不要用Encoding.Default——后者在不同机器上可能是 GBK 也可能是别的行为不可预测。// 去掉可能的 BOM 和首尾空白避免服务端解析失败 static string Normalize(string json) json?.Trim().TrimStart(\uFEFF) ?? {};5.3 界面假死.Result和.Wait()的死锁现象调试时点了按钮窗口直接白屏任务管理器显示进程无响应等几十秒后弹超时异常。原因在 UI 线程上调用了ApiClient.PostJsonAsync(...).Result或者.Wait()。UI 线程被阻塞住而await之后的续体需要回到 UI 线程才能继续执行两边互相等待形成死锁。如果底层用了ConfigureAwait(false)续体不回 UI 线程死锁不会发生但界面照样卡住几十秒——因为阻塞本身就在卡线程。解决从事件处理器一路async到最底层中途不要出现.Result、.Wait()、.GetAwaiter().GetResult()。只有在无法改造成异步的入口比如老式同步 API 的实现里才用.GetAwaiter().GetResult()而且必须确认当时不在 UI 线程上。判断方法很简单SynchronizationContext.Current null就是不在。5.4 中文变问号响应头没给 charset现象请求成功状态码 200但表格里显示的订单备注、客户名称全是???或者方块。原因ReadAsStringAsync依赖响应头里的charset来决定解码方式。如果服务端返回Content-Type: application/json却忘了带charsetutf-8部分运行时会退回到系统默认编码中文就解错了。反过来服务端明确返回charsetgbk而你按 UTF-8 处理同样会乱。解决先读字节再按实际编码解码不要直接读字符串。byte[] raw await resp.Content.ReadAsByteArrayAsync().ConfigureAwait(false); // 优先用响应头声明的编码没有就默认 UTF-8 var charset resp.Content.Headers.ContentType?.CharSet; Encoding enc string.IsNullOrEmpty(charset) ? Encoding.UTF8 : Encoding.GetEncoding(charset.Trim()); string text enc.GetString(raw);charset的值可能带引号比如charsetutf-8所以要Trim()。如果服务端用的是 GBK在 .NET Core / .NET 5 上还需要注册CodePagesEncodingProvider.Instance否则Encoding.GetEncoding(gbk)会抛NotSupportedException这个异常信息很明确看到就补注册。5.5 重复提交与跨线程按钮没锁、控件没回主线程现象一网络稍慢用户连点三次查询按钮服务端收到三条一样的记录。现象二程序偶发抛InvalidOperationException线程间操作无效尤其是在catch块里改控件文字时。原因按钮没有在请求期间禁用Click事件可以重入。跨线程异常则是因为某段代码跑在了线程池线程上——要么用了Task.Run包住整个请求再在里面改控件要么用了ConfigureAwait(false)之后又碰了 UI。解决请求开始就禁用按钮、结束在finally里恢复配合一个bool或CancellationTokenSource判空做双保险。控件更新统一放回await之后的代码里如果确实在后台线程用control.Invoke(new Action(() {...}))或者control.BeginInvoke包一层。后者是异步投递不会阻塞后台线程更适合高频更新场景。提示Control.InvokeRequired在窗体句柄还没创建时恒为false构造函数里调这个方法做判断会失效。控件更新还是放在Load之后的事件里最稳妥。6. 收尾技巧用一次「重放」把接口边界摸清接口联调最耗时的不是写请求而是猜服务端在边界条件下怎么回。我的做法是给程序留一个「重放」入口把每次请求的原始报文落盘再写一个小面板能从日志里挑一条记录、改几个字段、原样再发一次。有了它验证边界用例的成本从「改代码、重编译、跑起来」降到「改一个输入框、点一下按钮」。重放日志建议至少包含这几列缺一列排查时就会卡住字段用途时间戳毫秒对齐服务端日志确认是不是同一次调用完整 URL 含查询串排除路径拼接和参数丢失请求体原文复现问题时直接粘给对方状态码与耗时区分业务失败和网络失败响应体前 4KB看错误码和提示不必存全量配合重放我会固定跑一组边界用例空字符串、超长字符串比如 500 个汉字、含引号和反斜杠的文本、时间字段传空、分页参数传 0 和 -1、数组传空[]。这七八个用例跑下来服务端的校验规则基本就摸清了比读文档快也比等线上出问题再补强得多。还有一个细节HttpClient的Timeout和CancellationTokenSource的定时器不要设成一样长。两个都设 15 秒时先触发的那个决定了异常类型日志里就分不清到底是哪一层中止的。我一般让CancellationTokenSource比HttpClient.Timeout多 5 秒这样超时一定先由HttpClient抛出能明确判断是网络层超时。血泪经验是早期一个批量导入工具为了省事在循环里每次都new HttpClient()前两百条正常第三百条开始变慢第五百条直接抛连接异常日志里只有一行「An error occurred while sending the request」完全看不出是端口耗尽。从那以后我每次新建请求层都会先把实例改成静态复用、把超时和取消分开配置、把原始报文落盘这三件事强制走一遍再往下写业务。希望帮到你。本文还有配套的精品资源点击获取
