最稳妥方式是复用单例HttpClient并设置BaseAddress，异步调用GetAsync/PostAsJsonAsync，检查IsSuccessStatusCode，Bearer认证设DefaultRequestHeaders，合理配置超时与异常处理。
直接用 HttpClient 异步调用 Web API 是最稳、最可控的方式，别碰 WebClient 或同步阻塞写法；关键不是“会不会 await”，而是“实例怎么活”和“错误怎么判”。
HttpClient 实例必须复用，不能每次 new
频繁 new HttpClient() 会快速耗尽本地端口，尤其在循环或高并发调用中，几分钟就可能触发 SocketException: Too many open files。这不是偶发问题，是设计层面的硬伤。
- ✅ 推荐：在
Program.cs（.NET 6+）或Startup.cs中注册为单例：services.AddSingleton<httpclient>()</httpclient> - ✅ 更优（ASP.NET Core）：用
IHttpClientFactory，它自动管理连接池和 DNS 刷新，避免服务 IP 变更后请求持续发错地址 - ⚠️ 绝对禁止：在方法内写
using var client = new HttpClient()—— 这等于主动制造连接风暴 - ⚠️ 注意：即使声明为静态字段，也要显式设置
BaseAddress和Timeout，否则默认超时是 100 秒，太长
GetAsync 和 PostAsJsonAsync 必须 await，且要检查状态码
GetAsync 和 PostAsJsonAsync 返回的是 Task<httpresponsemessage></httpresponsemessage>，不 await 就读取内容，轻则返回空字符串，重则在 WinForms/WPF 中引发死锁。
- ✅ 正确顺序：先
await client.GetAsync("api/users")→ 再判断response.IsSuccessStatusCode→ 最后await response.Content.ReadAsStringAsync() - ✅ 更省事：调用
response.EnsureSuccessStatusCode()，它会在 401/403/500 等非 2xx 状态时直接抛HttpRequestException，不用手动 if - ⚠️ 坑点：401 Unauthorized 不算“异常”，
GetAsync会照常返回，但ReadAsStringAsync()可能因响应体为空或格式异常而崩 - ⚠️ 注意：
PostAsJsonAsync需引用System.Net.Http.Json包（.NET Core 3.1+ 默认含），老项目要手动加 NuGet
Bearer Token 认证必须设在 DefaultRequestHeaders，且 Token 要动态更新
绝大多数 Web API 要求 Authorization: Bearer xxx，这个头不能每次请求都手动加，也不能硬编码在初始化里——Token 通常有有效期，过期后需刷新。
- ✅ 推荐做法：在
IHttpClientFactory配置阶段用委托注入逻辑，例如：client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", GetCachedToken()) - ✅ 更健壮：封装一个带 Token 自动续期的
DelegatingHandler，拦截 401 后静默刷新再重试（需配合RefreshToken） - ⚠️ 坑点：Token 字符串里如果含空格或特殊字符，没做
Uri.EscapeDataString处理，可能导致认证失败且错误信息极不明确 - ⚠️ 注意：不要把 Token 存在静态变量里长期不校验有效性，尤其在多用户共享客户端实例的场景下
真正难的从来不是“怎么发请求”，而是让 HttpClient 在 DNS 变更、服务重启、Token 过期、连接卡死这些真实故障下还能自动恢复——这些细节不写进日志，就只能靠压测和线上报警才能暴露。
