Go的http.Client默认完全不设超时；只设Client.Timeout会漏掉DNS、TCP建连、TLS握手三阶段，因该字段仅覆盖连接建立后的读取阶段，前置环节需通过Transport.DialContext、TLSHandshakeTimeout和ResponseHeaderTimeout分别控制。
Go 的 http.Client 默认完全不设超时，只配 Timeout 字段会漏掉 DNS、TCP 建连、TLS 握手三个最常卡死的环节——线上服务跑半天后，netstat 里全是 SYN_SENT 或 ESTABLISHED 却无响应的连接，pprof 里堆着上百个 stuck 在 connect 或 handshake 的 goroutine。
为什么只设 Client.Timeout 还是会卡住
Client.Timeout 只从 client.Do() 调用开始计时，且仅覆盖“连接已建立之后”的阶段：发请求、等响应头、读响应体。它对以下环节完全无效：
- DNS 查询阻塞（比如
/etc/resolv.conf配了不可达的 nameserver，getaddrinfo会重试数秒甚至十几秒） - TCP 连接被防火墙拦截、SYN 重传超时（Linux 默认重试 6 次，耗时可达 3 分钟）
- TLS 握手因 OCSP Stapling、证书链验证或弱网延迟卡住（默认
TLSHandshakeTimeout是 10 秒，但未显式设置就等于 0）
这些阶段一旦出问题，Client.Timeout 根本不会触发，goroutine 和文件描述符持续泄漏。
http.Transport 必须显式配置的三个超时字段
真正可控的方式是自定义 http.Transport，把网络链路拆成可管理的环节。这三个字段必须同时设置，缺一不可：
立即学习“go语言免费学习笔记（深入）”；
-
DialContext：用&net.Dialer{Timeout: 5 * time.Second}控制 DNS + TCP 建连总时长——这是第一道防线，也是最常超时的环节 -
TLSHandshakeTimeout：显式设为3 * time.Second或5 * time.Second，避免 TLS 协商拖太久；HTTP/2 连接也走这个超时 -
ResponseHeaderTimeout：从连接建立完成起，到收到完整 status line + headers 的最大时间，推荐2 * time.Second，防后端已接受连接但拒绝返回 header（如进程卡在日志刷盘）
注意：ResponseHeaderTimeout 不管 body 读多久——如果调用流式接口，body 读取超时得靠 io.CopyN 或 bufio.Reader.Read 配合 context 自己控制。
单次请求必须用 context.WithTimeout 构造 http.Request
context.WithTimeout 是唯一能穿透 DNS、dial、TLS 全链路的取消机制，但它只在你正确传入时才生效：
- 必须用
http.NewRequestWithContext(ctx, method, url, body)构造请求，而不是req.WithContext(ctx)后再传给client.Do()—— 后者只影响读取响应，不中断底层 dial -
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)创建后，务必defer cancel()，否则 context 泄漏会导致 goroutine 和连接无法回收 - 错误判断必须用
errors.Is(err, context.DeadlineExceeded)，不是字符串匹配"timeout"，也不是类型断言net.Error
示例关键片段：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com", nil)
resp, err := client.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
// 真正的超时，可记录 metric 或降级
}
}别复用没设超时的全局 http.DefaultClient
直接用 http.Get() 或未改造的 http.DefaultClient，等于使用一个 Timeout: 0 的 client——它所有 Transport 字段也都是零值，DNS、dial、TLS 全部无上限。生产环境应为不同业务场景构造独立 http.Client 实例：
- 支付类接口可设更长的
Timeout（如 30s），但DialContext仍要压到 5s，避免前置卡死 - 内部服务调用建议用短
ResponseHeaderTimeout（1–2s），快速失败，别让慢依赖拖垮整条链路 - 禁用中间件偷偷替换
http.DefaultClient.Transport，容易造成隐式行为污染，排查困难
最容易被忽略的一点：超时配置不是一次性写完就完事。当服务部署在容器里，/etc/resolv.conf 配置不当（比如只写了 unreachable 的 nameserver）时，DNS 查询可能比预期慢得多——这时光调 DialContext.Timeout 不够，还得检查宿主机 DNS 设置和容器网络模型。
