httpclient.timeout仅控制请求发送到响应头接收的时间，不涵盖dns解析、tcp连接或tls握手；需配合connecttimeout（.net 6+）、cancellationtoken、ihttpclientfactory等分层设限防假死。
HttpClient.Timeout 只控制单次请求，不控制连接建立或 DNS 解析
很多人设了 HttpClient.Timeout = TimeSpan.FromSeconds(10) 就以为万事大吉，结果遇到 DNS 卡住、TCP 连接挂起、TLS 握手卡死等情况，请求照样“假死”超过 10 秒。这是因为 Timeout 仅作用于从发送完请求头/体到收到完整响应头之间的时间，不覆盖底层 Socket 连接阶段。
实操建议：
- 必须配合
HttpClientHandler.MaxConnectionsPerServer和HttpClientHandler.PooledConnectionLifetime防止连接池拖慢整体响应 - DNS 超时无法通过 HttpClient 直接控制，需改用
Dns.GetHostAddressesAsync(host, cancellationToken)配合CancellationTokenSource单独设限 - TCP 连接超时在 .NET 6+ 才支持（
HttpClientHandler.ConnectTimeout），旧版本只能靠外部取消逻辑兜底
用 CancellationToken 主动中断“卡住”的请求
这是最可靠、跨版本通用的防假死手段。Timeout 是被动等待，而 CancellationToken 是主动拔线——哪怕底层还在等 SYN-ACK 或 TLS ServerHello，也能立刻终止。
常见错误现象：只传 cancellationToken 给 GetAsync，但没给 HttpClient 构造时传 HttpClientHandler 的 UseProxy 或 AutomaticDecompression 等耗时环节留出响应窗口。
实操建议：
- 始终把
CancellationTokenSource创建和超时设定放在调用前，不要复用已触发的 token - 对长轮询、文件上传等场景，考虑用
CancellationTokenSource.CreateLinkedTokenSource合并业务取消信号与超时信号 - 注意：.NET Core 3.1+ 中，
HttpClient.SendAsync对已取消的 token 会立即抛OperationCanceledException，而非静默返回失败
.NET 6+ 新增 ConnectTimeout：解决 TCP 建连卡死
如果你用的是 .NET 6 或更新版本，HttpClientHandler.ConnectTimeout 是真正能拦住“连不上服务器”这类问题的关键配置。它控制从发起 TCP connect() 到完成（或失败）的最大时间，单位是 TimeSpan。
使用场景：内网服务偶尔因防火墙策略抖动、K8s Pod 启动慢、LB 转发延迟高等导致建连耗时突增。
实操建议：
- 设值建议比业务总超时小 2–3 秒，例如总超时 10 秒，
ConnectTimeout设为TimeSpan.FromSeconds(7) - 该属性只在
HttpClientHandler实例上生效，且必须在HttpClient初始化前设置，运行时修改无效 - Windows 上底层依赖 SocketsHttpHandler，Linux/macOS 表现一致；但若启用了
UseProxy = true，则实际建连路径可能绕过此超时（走代理握手）
别把 HttpClient 当一次性的对象来 new
频繁 new HttpClient 不仅引发端口耗尽（SocketException: Only one usage of each socket address is permitted），还会让超时设置失效——因为每个新实例都重置连接池和内部状态，DNS 缓存、keep-alive 复用全丢掉，间接拉长平均响应时间。
性能影响：实测在高并发下，每秒新建 100 个 HttpClient 实例，30 秒后可能出现 20%+ 请求因端口不足而直接失败。
实操建议：
- 全局复用一个
static readonly HttpClient，或用IHttpClientFactory（推荐）管理生命周期 - 用
IHttpClientFactory时，超时必须在命名客户端配置里设（AddHttpClient("api", c => { ... }).ConfigurePrimaryHttpMessageHandler(...)），不能在每次 GetService 之后再改Timeout - 如果真需要不同超时策略，定义多个命名客户端，而不是临时 new handler
真正的难点不在设哪个属性，而在于分清“谁在卡”：是 DNS？TCP？TLS？还是服务器根本没回包？不同卡点得用不同机制打断，混用或漏配都会让超时形同虚设。
