直接 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()。