Go的http.Client默认无超时，生产环境必须显式设置Client.Timeout、Transport.DialContext、TLSHandshakeTimeout和ResponseHeaderTimeout四类超时，否则DNS、TCP建连、TLS握手等阶段可能永久阻塞。
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，但别传错位置
硬编码 Client.Timeout 会让所有请求共用一个值，没法按接口粒度调整（比如查用户要 2s，支付回调要 30s）。这时候优先用 context.WithTimeout 包一层请求上下文：
- 必须调用
http.NewRequestWithContext(ctx, ...)，不是先NewRequest再补WithContext - 错误判断要检查
errors.Is(err, context.DeadlineExceeded)，而不是字符串匹配"timeout" - 收到
context.DeadlineExceeded就该立刻返回，别再尝试读resp.Body -
cancel()必须调用，建议defer cancel()，否则 context 泄漏
常见错误写法：client.Do(req.WithContext(ctx)) —— 这样 ctx 不会穿透到 DialContext 阶段。
别复用未设超时的全局 http.DefaultClient
直接用 http.Get 或 http.DefaultClient 发起请求，等于使用一个 Timeout: 0（即无超时）的 client——线上服务跑几天后，常会发现数百个 stuck 在 read tcp 或 connect 状态的 goroutine。
所有对外 HTTP 调用，都应使用自定义 http.Client 实例，且明确设置 Timeout 和 Transport 子项。若需复用 client（推荐），请确保其超时配置符合该调用场景；不同延迟特征的下游服务，不要共用同一 client。
最易被忽略的是：超时不是设一个数字就完事；DNS、建连、TLS、header 返回、body 流式读取，每个阶段的阻塞原因都不同，必须分层控制——漏掉任意一环，就可能在线上突然卡住几十秒甚至几分钟。
