HttpClient.Timeout仅控制请求体发完到响应头接收完成，不涵盖DNS查询、TCP建连和TLS握手；.NET 6+需配HttpClientHandler.ConnectTimeout防建连卡死，跨版本最可靠的是CancellationToken主动中断。
HttpClient.Timeout 只管“发完到收头”，不管 DNS 和建连
HttpClient.Timeout 看起来是总超时，其实只覆盖从请求体发送完毕到响应头接收完成这一段。DNS 查询、TCP 三次握手、TLS 握手全都不在它管辖范围内——这些阶段卡住，请求照样假死，远超你设的 10 秒。
常见错误现象：client.Timeout = TimeSpan.FromSeconds(10) 后仍遇到 20+ 秒无响应，抓包发现卡在 SYN 或 DNS query 阶段。
- .NET 6+ 才有
HttpClientHandler.ConnectTimeout控制 TCP 建连耗时，旧版本只能靠CancellationToken主动中断 - DNS 超时必须单独处理，例如用
Dns.GetHostAddressesAsync(host, cancellationToken)配合独立CancellationTokenSource.CancelAfter - 不要复用已触发的
CancellationToken，每次请求都应新建或用CreateLinkedTokenSource合并业务信号
.NET 6+ 必配 ConnectTimeout 防建连卡死
如果你用的是 .NET 6 或更新版本，HttpClientHandler.ConnectTimeout 是唯一能真正拦住“服务器连不上”这类问题的配置项。它作用于底层 connect() 系统调用，单位是 TimeSpan。
使用场景：K8s Pod 启动慢、内网 LB 转发延迟、防火墙策略抖动导致建连突增。
- 设值建议比业务总超时小 2–3 秒，例如总超时 10 秒，
ConnectTimeout设为TimeSpan.FromSeconds(7) - 必须在
HttpClientHandler上设置，不能直接设在HttpClient实例上 - 该属性对
HttpClientFactory注册的命名客户端同样生效，但需确保 handler 实例被正确传递
用 CancellationToken 才是跨版本最可靠的“拔线”手段
HttpClient.Timeout 是被动等，CancellationToken 是主动断——哪怕底层还在等 TLS ServerHello，也能立刻终止整个请求链路。
常见错误现象：只把 cancellationToken 传给 GetAsync，却没考虑 HttpClientHandler 构造时的 UseProxy、AutomaticDecompression 等环节可能耗时；或者复用了已取消的 token 导致后续调用直接抛 OperationCanceledException。
- 始终在调用前创建
CancellationTokenSource，例如using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10)) - 长轮询、文件上传等场景，用
CancellationTokenSource.CreateLinkedTokenSource合并业务取消信号与超时信号 - .NET Core 3.1+ 中，
SendAsync对已取消的 token 会立即抛OperationCanceledException，不会静默失败
别试图动态改单例 HttpClient 的 Timeout
一旦 HttpClient 发起过请求，再改 Timeout 就会抛异常：This instance has already started one or more requests. Properties can only be modified before sending the first request.
这意味着你没法靠“复用一个 client + 每次改 Timeout”来实现 per-request 超时——这不是设计缺陷，而是底层连接池和管道机制决定的硬限制。
- 需要不同超时的请求，应使用多个命名客户端：
services.AddHttpClient("fast", c => c.Timeout = TimeSpan.FromSeconds(3)) - 若必须动态控制，推荐封装
HttpRequestMessage+Properties字典存超时值，再配合自定义DelegatingHandler在SendAsync中提取并注入CancellationToken - 绝对避免在 using 块里 new
HttpClient，也避免全局单例——前者端口耗尽，后者无法响应 DNS 变更且默认头污染风险高
真正难的不是设哪个属性，而是分清 DNS、TCP、TLS、HTTP 四层各自卡点在哪，再选对应手段。超时从来不是单一开关，而是一组协同的熔断策略。
