HttpClient 实例必须复用，不能每次 new
频繁创建
HttpClient实例会导致端口耗尽、DNS 查询重复触发、连接无法复用，这是高并发下最典型的根源问题。.NET 默认的
DnsEndPoint解析行为在实例销毁时不会保留缓存，新实例会重新查 DNS —— 即使目标域名没变，也可能拿到不同 IP（尤其在滚动发布或负载均衡场景）。 永远使用单例或
IHttpClientFactory创建客户端，不要在方法内
new HttpClient()直接 new 的
HttpClient即使调用了
Dispose()，底层
Socket仍可能处于
TIME_WAIT状态，持续占用本地端口 .NET 5+ 中，
HttpClient构造函数接受
HttpMessageHandler，但自定义
SocketsHttpHandler时务必复用该 handler 实例，否则连接池失效
显式配置 SocketsHttpHandler 提升 DNS 和连接稳定性
默认的
HttpClient使用系统级 DNS 缓存（如 Windows 的 DNS Client 服务），但不可控、不透明，且超时策略与 HTTP 超时不一致。应通过
SocketsHttpHandler显式控制 DNS 解析行为和连接生命周期。
DnsRefreshTimeout设为
TimeSpan.FromMinutes(2)可强制定期刷新 DNS，避免因 DNS TTL 过长导致流量卡在下线节点
PooledConnectionLifetime建议设为
TimeSpan.FromMinutes(5)，防止长连接僵死；设为
TimeSpan.Zero则禁用自动回收（不推荐）
PooledConnectionIdleTimeout控制空闲连接存活时间，默认 2 分钟，短于后端 LB 的 idle timeout 可能导致
Connection reset启用
AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate减少传输体积，间接降低连接压力
var handler = new SocketsHttpHandler
{
DnsRefreshTimeout = TimeSpan.FromMinutes(2),
PooledConnectionLifetime = TimeSpan.FromMinutes(5),
PooledConnectionIdleTimeout = TimeSpan.FromMinutes(4),
AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
};
var client = new HttpClient(handler); // 复用此 client 或注入 IHttpClientFactory
遇到 “No such host is known” 或 DNS 解析失败，先检查线程上下文
在 ASP.NET Core 高并发请求中，若使用
Task.Run或非 async/await 模式调用
HttpClient，DNS 查询可能运行在无网络权限的线程池上下文里，尤其在容器或受限网络策略环境中，表现为偶发性
HttpRequestException内嵌
SocketException：
No such host is known。 确保所有 HTTP 调用走真正的异步路径：
await client.GetAsync(...)，而非
client.GetAsync(...).Result或
.Wait()不要在
ConfigureAwait(false)后直接做 DNS 相关操作（虽然 handler 层已封装，但自定义
IDnsClient时需注意） 若必须同步等待（极少见），改用
GetAwaiter().GetResult()并确认调用线程具备网络能力（如非
ThreadPool.UnsafeQueueUserWorkItem） 容器环境（如 Kubernetes）中，检查
/etc/resolv.conf是否被覆盖、是否启用了
ndots导致搜索域追加失败
IHttpClientFactory 是生产环境唯一推荐方案
手动管理
SocketsHttpHandler容易遗漏重试、日志、指标等关键能力。.NET Core 2.1+ 的
IHttpClientFactory不仅封装了连接池和 DNS 行为，还内置了命名客户端、类型化客户端、策略（Polly）集成和诊断事件。 注册时用
AddHttpClient<myapiclient>("github")</myapiclient>，然后在构造函数中接收 IHttpClientFactory，调用
_factory.CreateClient("github")
它自动复用底层 SocketsHttpHandler，并隔离不同命名客户端的连接池，避免一个服务异常影响全局连接 配合
ConfigurePrimaryHttpMessageHandler可统一设置 DNS 和连接参数，无需每个地方重复写
SocketsHttpHandler注意：工厂创建的
HttpClient实例本身可被
Dispose()，但底层 handler 不会释放 —— 这是设计使然，不是内存泄漏
DNS 缓存和连接管理的边界其实很窄：你控制不了操作系统 DNS 缓存，也很难绕过 NAT 或 LB 的连接超时，真正能稳住的只有 handler 的生命周期、参数精度和调用方式。漏掉其中任意一环，压测时丢包或解析失败就会准时出现。
