Go 中 http.Client 超时需分层配置：仅设 Client.Timeout 无法覆盖 DNS、TLS 等环节；应通过 Transport 显式设置 DialContext、TLSHandshakeTimeout 等；推荐用 context.WithTimeout 动态控制单次请求，并正确传入 NewRequestWithContext。
Go 中 http.Client 的超时设置必须分层配置
单纯给 http.Client 设置 Timeout 字段，只控制整个请求的总耗时（从 Dial 到读完 body），但无法覆盖 DNS 解析、TLS 握手等中间环节的阻塞。生产环境常见“请求卡住几十秒”问题，往往就出在这里。
正确做法是显式配置底层传输：http.Transport，并分别控制各阶段超时：
-
DialContext：控制建立 TCP 连接（含 DNS 查询）的最大等待时间 -
TLSHandshakeTimeout：限制 TLS 握手耗时 -
ResponseHeaderTimeout：从发送完 request 到收到 response header 的上限 -
IdleConnTimeout和KeepAlive：影响连接复用，间接影响并发稳定性
示例：
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 3 * time.Second,
ResponseHeaderTimeout: 5 * time.Second,
IdleConnTimeout: 30 * time.Second,
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
},
}用 context.WithTimeout 包裹单次请求更可靠
http.Client.Timeout 是全局兜底，而 context.WithTimeout 可以在每次请求时动态控制，尤其适合混合不同 SLA 的接口调用，或在链路中嵌入业务逻辑超时判断。
立即学习“go语言免费学习笔记（深入）”；
注意：必须把 context 传给 http.Request，而不是只传给 client.Do() —— 否则 DNS/TLS 阶段仍可能绕过 context 取消。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 创建带超时的 context：
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second) - 用
http.NewRequestWithContext(ctx, ...)构造 request - 调用
client.Do(req)，若超时会返回context.DeadlineExceeded错误 - 务必调用
cancel()避免 goroutine 泄漏（即使请求已完成）
错误写法：client.Do(req.WithContext(ctx)) —— 这不会影响底层 dial 行为，仅对读取 response 生效。
重试逻辑不能简单套 for 循环 + sleep
直接写 for i := 0; i 有三个硬伤：未区分可重试错误、未重置 request body（如 <code>io.ReadCloser 已被消费）、未做指数退避导致雪崩。
- 只对网络类错误重试：
url.Error的Err是*net.OpError或net/http.ErrServerClosed；HTTP 状态码 429/5xx 可按需重试，但 400/401/403 绝对不重试 - 若 request body 是
bytes.Reader或strings.Reader，可重复使用；若是os.File或自定义io.ReadCloser，必须在每次重试前重建 - 推荐用
time.Sleep(time.Second * time.Duration(1 做基础指数退避，加 jitter 防止同步冲击
更稳妥的做法是用现成库如 hashicorp/go-retryablehttp，它已处理 body 重放、错误分类和 backoff 策略。
并发请求下超时与重试的组合容易引发 goroutine 泄漏
当用 sync.WaitGroup + go func() 启动一批请求，并在每个 goroutine 内做重试，若某次重试因超时提前退出但未消费 response body，或未调用 cancel()，就会导致底层连接不释放、context goroutine 持续存活。
- 每个
http.Response必须调用resp.Body.Close()，无论是否读取成功 - 每个
context.WithTimeout创建的cancel函数，必须确保执行（可用defer cancel()，但注意闭包捕获问题） - 避免在重试循环内反复创建新 context，应在外层统一创建，重试时复用同一 context（或基于原 context 派生新子 context）
- 用
pprof定期检查/debug/pprof/goroutine?debug=1，确认无异常增长
最隐蔽的问题是：超时 error 被忽略，resp 为 nil，但代码仍试图 resp.Body.Close() —— 这会 panic。务必先判空。
