Go的http.Client必须显式配置三类超时：DialContext（DNS+TCP）、TLSHandshakeTimeout、ResponseHeaderTimeout；Client.Timeout仅覆盖连接建立后的读取阶段，不控制前置环节；禁用http.DefaultClient超时设置，应为各业务场景构造独立client实例。
Go 的 http.Client 默认完全不设超时，直接用 http.Get 或复用 http.DefaultClient 就等于放任请求无限卡死——这不是配置遗漏，是 Go 的明确设计；生产环境必须显式配三类超时，缺一不可。
为什么只设 Client.Timeout 还会卡在 DNS 或 TLS 握手
Client.Timeout 只覆盖“连接建立完成之后”的阶段：即从 TCP 连接成功、TLS 握手结束，到响应头+响应体全部读完的总耗时。它完全不控制前置环节：
- DNS 查询慢（比如
getaddrinfo阻塞） - TCP 连接被防火墙拦截、SYN 重传超时
- TLS 握手因证书链验证或 OCSP Stapling 卡住
这些阶段一旦出问题，Client.Timeout 根本不生效，goroutine 会永久挂起。必须通过 Transport.DialContext 和 Transport.TLSHandshakeTimeout 分别约束。
Transport 里必须配的三个关键字段
所有自定义 http.Client 实例都应显式构造 http.Transport，并设置以下三项（仅改 http.DefaultClient.Transport 无效，因它是私有结构且未初始化超时）：
立即学习“go语言免费学习笔记（深入）”；
-
DialContext：必须用&net.Dialer{Timeout: 5 * time.Second}构造，控制 DNS + TCP 建连总时长 -
TLSHandshakeTimeout：显式设为3 * time.Second或更短，避免弱网络下 TLS 卡住 -
ResponseHeaderTimeout：建议设为2 * time.Second，限定“连接建好后多久必须收到 status line + headers”，防后端已连上但拒绝响应
示例写法：
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 3 * time.Second,
ResponseHeaderTimeout: 2 * time.Second,
},
}用 context.WithTimeout 而不是 time.AfterFunc
time.AfterFunc 或裸 select + time.After 只能中断你自己的代码逻辑，底层 TCP 连接、DNS 查询、TLS 握手仍在后台运行，goroutine 和文件描述符持续泄漏。
正确做法是把 context 传给请求本身：
- 调用
http.NewRequestWithContext(ctx, ...)，而非先建 request 再补 context - 确保
err是context.DeadlineExceeded或context.Canceled时立刻返回，不要尝试读resp.Body - 如果用了自定义
RoundTripper，需手动检查ctx.Done()并提前退出
注意：context.WithTimeout 优先级高于 Client.Timeout，二者共存时以 context 为准。
别碰 http.DefaultClient 的超时字段
写 http.DefaultClient.Timeout = 5 * time.Second 看似省事，但这是无效操作——DefaultClient.Transport 是一个未初始化超时参数的私有 *http.Transport 实例，该赋值不会透传到底层 dialer 或 TLS 配置。更危险的是，全局修改会污染所有依赖默认 client 的第三方库（比如 Prometheus client、Redis 库的 HTTP health check），导致难以排查的超时行为漂移。
真正安全的做法：每个业务模块使用独立构造的 http.Client 实例，并按接口 SLA 设置对应超时（如支付回调 30s、用户查询 2s）。复用 client 是 OK 的，但复用前必须确认它的超时配置与当前调用场景匹配。
最易被忽略的一点：Timeout 不包含重定向耗时——若服务端返回 302，每次跳转都会重新计时一次 Timeout，不是累计。高跳转频率下，这个细节会让实际超时远短于预期。
