http.Client.Timeout 是整体请求总超时，会掩盖各阶段瓶颈；而 Transport 各阶段超时（如 DialContext.Timeout、TLSHandshakeTimeout、ResponseHeaderTimeout）可精准定位问题：前者控制从请求开始到结束的总时长，后者分别控制建连、TLS 握手、响应头等待等具体环节。
http.Client.Timeout 与 Transport 各阶段超时的区别
直接设 Client.Timeout 看似简单，但会掩盖连接建立、TLS 握手、响应头等待等不同阶段的真实瓶颈。比如 DNS 解析慢导致卡在 DialContext，而总超时还没到，你却无法定位是哪一环出问题。
更稳妥的做法是分层控制：
-
DialContext.Timeout：控制 TCP 连接建立（含 DNS 查询），建议 2–5 秒 -
TLSHandshakeTimeout：TLS 协商超时，通常比建连略短，1–3 秒较安全 -
ResponseHeaderTimeout：从发完请求到收到第一个字节响应头的时间，建议设为业务 P95 响应时间的 1.5 倍 -
IdleConnTimeout和MaxIdleConns：影响复用效率，不设或设太小会导致频繁重建连接，放大 TLS 开销
哪些错误类型值得重试？哪些必须立刻放弃？
重试不是万能药。盲目对所有 err != nil 重试，可能把 400 错误反复打过去，或让幂等性失控的 POST 请求重复扣款。
可重试的典型场景：
立即学习“go语言免费学习笔记（深入）”；
-
net.OpError且Temporary()返回 true（如timeout、connection refused） -
context.DeadlineExceeded（说明是上层主动中断，非服务端拒绝） - HTTP 状态码
502、503、504—— 这些代表网关/上游临时不可用
明确不该重试的：
- 任何 4xx 状态码（
400、401、404），除非是429且你已实现Retry-After解析 -
net/url.Error中包含"no such host"或"i/o timeout"以外的 DNS 错误（如dns.ErrNoAnswer），大概率配置错误，重试无意义
指数退避重试的实现要点
用 time.Sleep(100 * time.Millisecond) 固定间隔重试，在并发稍高时容易触发雪崩。必须用指数增长 + 随机抖动（jitter）。
实操建议：
- 基础间隔从
100ms起，每次 ×2，上限建议不超1s（第 4 次重试已是800ms） - 每次 sleep 前加
rand.Float64() * 0.2抖动，避免大量请求在同一毫秒重试 - 每次重试必须新建
*http.Request，因为req.Body可能已被读取或关闭；对 POST 请求，用bytes.NewReader包装原始 payload，确保可重放 - 不要复用同一个
context，每次重试应调用context.WithTimeout(ctx, retryTimeout)创建新 context
HTTPS 场景下 TLS 配置与超时的耦合风险
启用 TLS 后，TLSHandshakeTimeout 不只是“多一个超时参数”，它直接影响连接池行为。如果握手超时设得太短（如 500ms），而服务端 TLS 证书链长或 OCSP 响应慢，就会频繁断开空闲连接，导致 MaxIdleConns 形同虚设。
真实项目中容易被忽略的点：
- 若使用私有 CA 或自签名证书，需显式配置
Transport.TLSClientConfig.RootCAs，否则握手会卡在证书验证，超时后报错看似是网络问题，实则是信任链缺失 -
Transport.ForceAttemptHTTP2设为 true 时，TLS 握手失败不会 fallback 到 HTTP/1.1，错误更隐蔽 - 某些中间设备（如 WAF、API 网关）会对 TLS 握手做深度检测，响应延迟波动大，此时
TLSHandshakeTimeout应比DialContext.Timeout更宽松，而非更紧
实际部署时，最常被绕过的不是代码逻辑，而是 TLS 握手阶段的超时和证书信任配置——它们不出现在 HTTP 状态码里，也不触发常规重试判断，却能让整个连接流程静默失败数秒。
