直接 new HttpClient() 不适合高并发场景，因其导致端口耗尽、DNS 缓存失效、连接池无法复用；应复用单例 HttpClient 并显式配置 SocketsHttpHandler 的 MaxConnectionsPerServer、PooledConnectionIdleTimeout 等参数。
为什么直接 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()。
