正确设置 timeout 应新建独立 http.Client 实例，同时配置 client.Timeout（10–30s）和 transport 各超时参数；重试需分层判断网络错误与状态码，用 go-retryablehttp 并设合理次数。
怎么设置 timeout 而不踩 http.DefaultClient 的坑
直接改 http.DefaultClient 是全局污染，所有包里用的 HTTP 请求都会被影响，比如你引入的第三方库（如 aws-sdk-go、redis-go）可能悄悄发 HTTP 请求，它们也会被你的超时策略拖垮。
正确做法是每次新建独立的 http.Client 实例，并只在自己业务逻辑中显式传入。超时必须设在 http.Transport 和 http.Client 两个层级：
-
client.Timeout控制整个请求生命周期（从 dial 到读完 body），建议设为 10–30s -
transport.DialContext需包装net.Dialer设置Timeout（连接建立）和KeepAlive -
transport.TLSHandshakeTimeout单独设，避免 TLS 握手卡死（尤其在高延迟或弱网环境）
别漏掉 transport.IdleConnTimeout 和 transport.MaxIdleConnsPerHost，否则长连接堆积会耗尽文件描述符。
重试逻辑为什么不能写在 http.Client.Do() 外面简单 for 循环
因为不是所有错误都能重试：网络中断、DNS 失败、连接拒绝可以重试；但 4xx 响应（如 400 Bad Request、401 Unauthorized）重试毫无意义，5xx 中的 501 Not Implemented 也不该重试。盲目重试反而放大服务压力。
立即学习“go语言免费学习笔记（深入）”；
真正可靠的重试要分层判断：
- 底层网络错误（
url.Error+err.Timeout()或strings.Contains(err.Error(), "timeout")）→ 可重试 - HTTP 状态码在
[500, 599]且非501、505→ 可重试 - 重试前必须检查是否已读 body（
resp.Body.Close()），否则下一次Do()会 panic - 用指数退避（如
time.Second * (2 ^ attempt)），别固定 sleep 1s
别自己手写重试循环——用 github.com/hashicorp/go-retryablehttp 更稳，它内置了上述判断，且支持自定义 check 函数。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
怎么让自定义 client 支持 context 取消和 trace 注入
HTTP 请求必须能响应上游 context 的 cancel，否则超时或用户中断后 goroutine 还在等 socket，容易 leak。
关键点只有两个：
- 调用
client.Do(req.WithContext(ctx))，而不是client.Do(req) - 确保 transport 层没屏蔽 context（老版本 Go 的某些自定义
DialContext实现会忽略 ctx.Done()）
如果要加 OpenTelemetry trace，别动 client 本身——在构造 *http.Request 时注入 header：req.Header.Set("traceparent", span.SpanContext().TraceID().String())。注意：不要在重试时重复注入，否则 trace 链路会断。
为什么封装成函数比封装成 struct 更轻量也更安全
很多人喜欢定义 type HTTPClient struct { client *http.Client; retryOpts ... }，但实际使用中，你几乎不会在 client 上挂状态（比如计数器、缓存 map），反而容易误用：比如把带重试的 client 和不带重试的混用，或者忘记初始化字段导致 panic。
更自然的方式是导出一个函数：
func NewHTTPClient(timeout time.Duration, enableRetry bool) *http.Client {
// 构建 transport + client
// 根据 enableRetry 决定是否 wrap retry logic
return client
}这样调用方一眼看清行为边界，也不会意外复用错误配置的实例。如果真需要共享状态（比如 metrics 计数），用单独的 metrics.HTTPRoundTripper 包一层更清晰。
最常被忽略的是：重试次数上限默认是 3，但很多场景（如调内部服务）应该设为 1 或 2；而调外部 API（如支付回调）可能需要 5 次+，这个阈值必须按目标服务 SLA 显式指定，不能靠“先试试看”。
