HttpClient.SendAsync 不会阻塞线程，它基于异步 I/O 机制实现；但误用 .Wait() 或 .Result 会导致死锁。应始终 await 调用，复用 HttpClient 实例推荐使用 IHttpClientFactory，响应读取需在作用域内完成，超时与重试需协同配置。
HttpClient.SendAsync 会阻塞线程吗？
不会，
是真正的异步方法，底层基于
和操作系统 I/O 完成端口（Windows）或 epoll/kqueue（Linux/macOS），不占用线程池线程等待响应。但如果你在 UI 线程或 ASP.NET 同步上下文中用
或
强行同步等待，就会引发死锁或线程饥饿。
实操建议：
始终用
调用
，不要用
避免在 ASP.NET Core 旧版（如 .NET Framework + WebForms）中混用同步/异步模式
如果必须同步调用（极少数嵌入式或测试场景），改用
，它才是同步阻塞版本
如何正确复用 HttpClient 实例？
新版
（.NET Core 2.1+）不是线程安全的“一次性对象”，但也不是“随便 new”。频繁创建销毁会导致端口耗尽（
）；长期单例又可能忽略 DNS 变更或连接泄漏。
实操建议：
在 .NET Core / .NET 5+ 中，优先用
注册，由 DI 容器管理生命周期
手动管理时，将
声明为
或单例服务，而非方法内
不要给每个请求都 new 一个
，尤其在高并发循环中
若需不同配置（如超时、证书），用
创建命名客户端，而非直接 new
响应体读取失败：ReadAsStringAsync 报 ObjectDisposedException？
常见于未 await 就返回响应对象，或在 using 块外访问已释放的
。.NET 6+ 默认启用
行为（
默认 true），导致响应流随
一起被释放。
实操建议：
确保
在
作用域内完成
不要把
存到字段或跨 async 方法传递
需要多次读取时，先调用
缓存字节，再解析
禁用自动释放（不推荐）：构造
时设
，但需手动调用
超时与重试怎么配才不互相打架？
控制整个请求生命周期（DNS + 连接 + 发送 + 接收），而重试逻辑（如
）通常在请求抛出异常后触发。如果
太短，重试还没开始就已失败；如果重试策略没排除
，还会把超时当可重试错误。
实操建议：
设
为「单次尝试最大容忍时长」，例如 10 秒
用
的
+ 自定义条件过滤
（仅重试网络中断类异常，跳过超时）
重试间隔应指数退避，避免雪崩；总重试耗时需明显小于
调试时开启
日志：
日志级别设为
真正容易被忽略的是 DNS 缓存和连接池老化——即使你用了
，默认连接空闲 2 分钟后会被关闭，而 DNS 记录可能缓存更久。生产环境遇到间歇性 503 或连接拒绝，得查
和 DNS TTL，不是换库就能解决的。
SendAsyncTask.Wait().ResultawaitSendAsync.GetAwaiter().GetResult()HttpClient.SendHttpClientSocketException: Address already in useIServiceCollection.AddHttpClient()HttpClientstatic readonlynewHttpClientIHttpClientFactoryHttpContentDisposeResponseHttpRequestMessage.DisposeRequestHttpResponseMessageawait response.Content.ReadAsStringAsync()responseresponse.Contentresponse.Content.ReadAsByteArrayAsync()HttpRequestMessageDisposeRequest = falseresponse.Dispose()HttpClient.TimeoutPollyTimeoutOperationCanceledExceptionHttpClient.TimeoutPollyHandleTransientHttpError()OperationCanceledExceptionTimeoutHttpClientMicrosoft.Extensions.HttpDebugIHttpClientFactoryHttpClientHandler.MaxConnectionsPerServer