为什么直接 new HttpClient() 不适合高并发场景
默认的
HttpClient实例会复用底层
SocketsHttpHandler，但若每次请求都新建
HttpClient（比如在方法内
new HttpClient()），会导致端口耗尽、DNS 缓存失效、连接池无法复用。真正可控的并发优化入口是显式配置
SocketsHttpHandler，而不是调用时机。
SocketsHttpHandler 的关键并发参数设置
这些参数直接影响连接建立速度、复用率和最大并行请求数。必须通过构造函数传入
SocketsHttpHandler，再传给
HttpClient：
MaxConnectionsPerServer：单个服务器地址（含端口）允许的最大空闲 + 正在使用的连接数。设为
100或更高时需确认系统文件句柄足够；设为
int.MaxValue并不推荐，容易触发 OS 限制
PooledConnectionLifetime：连接在池中存活时间，默认
2 分钟。设为
TimeSpan.Zero表示永不过期，但可能遇到服务端主动断连后首次复用失败（表现为
HttpRequestException带 “The operation was canceled”）
PooledConnectionIdleTimeout：空闲连接保留在池中的最长时间，默认
2 分钟。比
PooledConnectionLifetime更常调整，尤其在服务端连接超时较短（如 30 秒）时，应设为略小于该值（如
25 秒）
KeepAlivePingDelay和
KeepAlivePingTimeout：.NET 6+ 支持，用于 HTTP/2 长连接保活。非必要不开启，开启后会增加心跳开销
var handler = new SocketsHttpHandler
{
MaxConnectionsPerServer = 100,
PooledConnectionIdleTimeout = TimeSpan.FromSeconds(25),
PooledConnectionLifetime = TimeSpan.FromMinutes(2),
EnableMultipleHttp2Connections = true // .NET 5+
};
var client = new HttpClient(handler);
注意 DNS 缓存与连接池的耦合关系
SocketsHttpHandler默认使用系统 DNS 解析，且解析结果不缓存（或缓存极短）。当域名对应多个 IP（如负载均衡）时，
MaxConnectionsPerServer是按每个 IP 单独计数的。这意味着： 若 DNS 返回 3 个 A 记录，实际最多可建
100 × 3 = 300条连接，但客户端无法感知服务端真实负载分布 频繁 DNS 变更（如蓝绿发布）可能导致部分连接持续打向已下线节点，除非
PooledConnectionLifetime足够短 如需精确控制，可配合
DnsEndPoint或自定义
INameResolutionProvider（.NET 7+），但多数场景只需确保
PooledConnectionLifetime≤ DNS TTL
不要忽略 HttpClient 生命周期管理
即使配好了
SocketsHttpHandler，如果把
HttpClient当作局部变量反复创建，所有配置都白搭。正确做法是： 全局单例（如 DI 容器中注册为
Singleton），或至少按域名粒度复用 避免在
using块中使用
HttpClient——
Dispose()会关闭整个连接池，下次新建又要重建连接 如果必须短期使用（如 CLI 工具），可考虑
HttpClientFactory，它内部也基于共享的
SocketsHttpHandler
真正影响并发性能的，从来不是某一行代码，而是连接池是否被跨请求复用、DNS 是否稳定、以及你有没有在错误的地方调用了
Dispose()。
