http.Client.Timeout仅作总兜底，会掩盖DNS、TCP、TLS、响应头等各阶段真实问题；必须通过Transport显式配置DialContext、TLSHandshakeTimeout、ResponseHeaderTimeout，并配合context实现分层超时控制。
http.Client.Timeout 会掩盖真实问题，别直接设它
很多人一上来就写 Timeout: 10 * time.Second，结果线上遇到 DNS 卡顿、服务端 header 不发、TLS 握手慢等问题时，只能看到笼统的 context deadline exceeded 或 net/http: request canceled，根本不知道卡在哪一环。
-
http.Client.Timeout是总耗时兜底，一旦非零，它会强制覆盖http.Transport里所有子超时（比如DialContext、TLSHandshakeTimeout），失去分阶段诊断能力 - 它对“服务端已返回 header 但 body 流式发送卡住”完全无效——因为超时计时在读完 body 才结束
- 容器环境里 /etc/resolv.conf 配置不当导致 DNS 查询重试多次，
Timeout只能干等，无法干预 DNS 层 - 正确做法：把
http.Client.Timeout设为0，所有超时交给http.Transport和context分层控制
Transport 的 DialContext 超时必须显式配置
这是连接建立阶段最常出问题的一环。默认情况下，Go 的 DialContext 没有超时，DNS 解析失败或目标 IP 不可达时，可能卡住几十秒甚至更久。
- 用
&net.Dialer{Timeout: 3 * time.Second}包裹DialContext，严格限制 TCP 连接建立（含 DNS 查询）耗时 - 务必同时设
KeepAlive: 30 * time.Second，避免连接池中空闲连接被中间设备静默断开 -
IdleConnTimeout建议设为90 * time.Second，太短会导致复用率下降；太长则可能保留失效连接 - 别漏掉
TLSHandshakeTimeout（HTTPS 场景），弱网下默认 10 秒太长，建议压到3 * time.Second
重试前必须 req.Clone(ctx)，否则 body 会变 nil
HTTP 请求体（比如 io.Reader 类型的 body）在第一次 client.Do() 后就被消费掉了。如果没 clone 就重试，第二次调用会传入一个已关闭或空的 body，常见报错是 http: invalid Read on closed Body 或静默发送空数据。
- 每次重试前必须调用
req = req.Clone(ctx)，其中ctx是新创建的、带本次重试独立 timeout 的 context - 不能复用外部传入的
ctx，否则第一次超时后ctx.Err()已为context.Canceled，后续重试直接失败 - 如果请求带自定义 header（如
Authorization），Clone()会保留，无需手动复制 - body 是
nil（GET 请求）或实现了io.Seeker（如bytes.NewReader）时可跳过 clone，但统一写req.Clone更安全
只对 net.Error 和 5xx 状态码重试，4xx 错误绝不重试
重试不是万能解药。盲目重试 4xx（如 400 Bad Request、401 Unauthorized、404 Not Found）只会放大错误，还可能触发风控限流。
立即学习“go语言免费学习笔记（深入）”；
- 先判断错误是否为
net.Error类型且Timeout()返回 true，或错误是context.DeadlineExceeded、net/http: request canceled - 再检查响应状态码：
resp.StatusCode >= 500 && resp.StatusCode < 600或resp.StatusCode == 429（限流）才考虑重试 - 遇到
json.SyntaxError、url.Error、http.ErrBodyReadAfterClose这类解析或使用错误，说明请求本身有问题，重试无意义 - POST/PUT 等非幂等请求，除非业务明确保证接口幂等，否则不应自动重试
实际部署时最容易被忽略的是：Transport 的 MaxIdleConns 和 MaxIdleConnsPerHost 默认值极低（前者为 100，后者为 0），高并发场景下若不调大，连接池会成为瓶颈，导致大量新建连接——这反过来又放大了 DialContext 超时的影响。
