GolangHTTP客户端进阶设置连接超时与重试-Golang-PHP中文网

http.client.timeout仅作总兜底，会掩盖dns、tcp、tls、响应头等各阶段真实问题；必须通过transport显式配置dialcontext、tlshandshaketimeout、responseheadertimeout，并配合context实现分层超时控制。

golanghttp客户端进阶设置连接超时与重试

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 或静默发送空数据。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

每次重试前必须调用 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）只会放大错误，还可能触发风控限流。

先判断错误是否为 net.Error 类型且 Timeout() 返回 true，或错误是 context.DeadlineExceeded、net/http: request canceled
再检查响应状态码：resp.StatusCode >= 500 && resp.StatusCode 或 <code>resp.StatusCode == 429（限流）才考虑重试
遇到 json.SyntaxError、url.Error、http.ErrBodyReadAfterClose 这类解析或使用错误，说明请求本身有问题，重试无意义
POST/PUT 等非幂等请求，除非业务明确保证接口幂等，否则不应自动重试