go http客户端超时是dial、tls、response三层叠加，需分别配置transport.dialcontext、tlshandshaketimeout和responseheadertimeout，client.timeout仅为兜底总时限且须大于各子超时之和。
Go HTTP客户端超时不是单个设置，而是三层叠加
很多人以为设了 http.Client.Timeout 就万事大吉，结果还是遇到卡死、连接 hang 住、TLS 握手无限等待——因为 Go 的 HTTP 超时是分层的：Dial（建连）、TLS（握手）、Response（读响应体）。任一层没控制，整条链就可能失控。
默认情况下，http.Client.Timeout 只覆盖从发起请求到读完响应头（不含响应体）的总时间，但不约束底层 TCP 连接建立或 TLS 握手。这意味着：即使你设了 5 秒超时，DNS 解析慢、服务端 SYN 包丢包、中间设备阻断 TLS ClientHello，都可能让请求卡在 net.Dial 或 tls.Client.Handshake 阶段，完全不触发 Timeout。
必须手动配置 Transport 才能控制 Dial 和 TLS 超时
真正可控的起点是 http.Transport。它负责底层连接复用、拨号、TLS 协商。只改 Client.Timeout 是治标；改 Transport.DialContext 和 Transport.TLSHandshakeTimeout 才是治本。
-
Transport.DialContext必须包装成带超时的拨号器，否则 DNS + TCP 建连无上限（尤其在内网 DNS 不稳或目标端口被防火墙静默丢包时） -
Transport.TLSHandshakeTimeout显式限制 TLS 握手耗时，避免因服务端证书异常、SNI 不匹配或 TLS 版本协商失败而无限等待 -
Transport.ResponseHeaderTimeout控制从连接建立完成到收到响应头的时间，比Client.Timeout更精准地隔离“发出去但没回包”的场景 -
Transport.ExpectContinueTimeout在启用Expect: 100-continue时有用，一般可忽略
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
tr := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 3 * time.Second,
ResponseHeaderTimeout: 5 * time.Second,
// 注意：这里不设 IdleConnTimeout 或 MaxIdleConnsPerHost，
// 否则可能误杀正在复用的健康连接
}
client := &http.Client{Transport: tr, Timeout: 10 * time.Second}Client.Timeout 和 Transport 超时的关系容易倒置
Client.Timeout 是兜底总时限，必须大于所有 Transport 子超时之和，否则 Transport 层还没触发超时，Client 就先 panic 了。常见错误是把 Client.Timeout 设得太小，比如 Transport 各环节加起来要 8 秒，却只设 Client.Timeout = 5 * time.Second，结果永远看不到 Dial 或 TLS 超时的具体错误，只看到 context deadline exceeded，无法定位到底是哪一环出问题。
- 典型合理组合：
DialContext.Timeout = 3s+TLSHandshakeTimeout = 3s+ResponseHeaderTimeout = 5s→Client.Timeout ≥ 12s - 如果
Client.Timeout小于任一 Transport 超时，Transport 层的超时逻辑实际不会生效 - 错误信息里出现
net/http: request canceled (Client.Timeout exceeded while awaiting headers)，说明是ResponseHeaderTimeout或Client.Timeout触发的；如果是net/http: request canceled while waiting for connection，才是 Dial 层的问题
HTTP/2 下 TLSHandshakeTimeout 会被绕过
Go 1.12+ 默认启用 HTTP/2，而 HTTP/2 连接复用会跳过重复的 TLS 握手——但首次建连仍走完整流程。更隐蔽的是：当 Transport 复用已存在的 HTTP/2 连接时，TLSHandshakeTimeout 完全不参与，此时实际依赖的是连接池中该连接的空闲状态和 IdleConnTimeout。这意味着：如果你压测时初始并发高，大量连接同时走 TLS 握手，TLSHandshakeTimeout 能起作用；但后续请求复用连接，超时控制就落到 IdleConnTimeout 和 ResponseHeaderTimeout 上。
- HTTP/2 场景下，
TLSHandshakeTimeout只对新建连接有效，对复用连接无效 - 不要依赖
TLSHandshakeTimeout来保护长周期的连接池行为 - 若服务端支持 HTTP/2 且你观察到 TLS 超时不生效，先确认是否复用了连接（看
http.Transport.IdleConnTimeout和日志中的reuse提示）
最易被忽略的一点：超时链不是线性相加，而是嵌套判断。Dial 超时失败后根本不会走到 TLS 阶段，TLS 失败也不会进入 Response 读取。所以调优必须从最底层开始逐层验证，不能只看最终错误类型。
