http.Client.Timeout不解决重试问题，因其仅控制单次请求总耗时并直接返回错误，不自动重试；需手动集成退避重试逻辑（如backoff.Retry v4），并精准判断可重试错误类型。
为什么直接用 http.Client 的 Timeout 不解决重试问题
因为 http.Client.Timeout 只控制单次请求的总耗时，超时后直接返回错误，不重试。网络抖动、临时 502/503、DNS 解析失败这些场景下，你需要的是“失败后等一会儿再试”，而不是立刻放弃。
Go 标准库本身不提供重试逻辑，必须自己封装或借助第三方包。最常用且可控的是组合 http.Client + backoff.Retry（来自 github.com/cenkalti/backoff/v4），它把退避策略和重试控制解耦得比较干净。
- 别用已归档的
v3版本，v4支持 Go modules 且修复了 context 取消传播问题 - 避免手写
for { select { case 循环：容易漏掉 context 取消、超时嵌套、指数退避计算出错 -
backoff.ExponentialBackOff默认最大间隔是 128 秒，对 API 调用通常太长，要手动设MaxInterval
如何用 backoff.Retry 包裹 HTTP 请求
核心思路是把一次 http.Do 封装成一个无参函数，返回 error；backoff.Retry 在错误非 nil 时按策略重试，直到成功或超出最大重试次数。
示例代码片段（关键部分）：
立即学习“go语言免费学习笔记（深入）”；
func doWithRetry(req *http.Request) (*http.Response, error) {
var resp *http.Response
err := backoff.Retry(func() error {
r, err := http.DefaultClient.Do(req)
if err != nil {
return err // 连接失败、超时等，可重试
}
if r.StatusCode >= 500 && r.StatusCode < 600 {
return fmt.Errorf("server error: %d", r.StatusCode) // 5xx 可重试
}
if r.StatusCode == 429 {
return fmt.Errorf("rate limited") // 429 也可重试，但建议加 Retry-After 处理
}
resp = r
return nil // 成功，停止重试
}, backoff.WithContext(backoff.NewExponentialBackOff(), req.Context()))
return resp, err
}
- 一定要用
backoff.WithContext，否则req.Context()取消无法中断重试循环 - 别在重试函数里复用
*http.Request：HTTP/1.1 不允许重用已读 body 的 request，需克隆或重建（见下一点） - 如果请求带 body（如 POST JSON），每次重试前必须重新构造
req.Body，否则第二次Do会读到空 body
如何安全地重试带 body 的 POST 请求
标准 *http.Request 的 Body 是 io.ReadCloser，读完即关闭，不能重复读。直接重试会导致后续请求 body 为空。
- 方案一（推荐）：把原始 payload 存为字节切片，每次重试时新建
bytes.NewReader(payload)赋给req.Body - 方案二：用
req.Clone(req.Context())并重置Body，但要注意 clone 不复制 body 数据，仍需手动处理 - 避免用
strings.NewReader直接传字符串——中文或特殊字符可能因编码出错，统一走[]byte+bytes.NewReader - 如果 payload 很大（>1MB），别反复拷贝，改用可 seek 的
bytes.Buffer或临时文件，但会增加复杂度，一般服务请求不建议
哪些错误不该重试，以及怎么定制判断逻辑
不是所有错误都适合重试。比如 400 Bad Request、401 Unauthorized、404 Not Found 是客户端问题，重试只是浪费资源。
- 重试应聚焦于临时性错误：
net.OpError（连接拒绝、超时）、url.Error（DNS 失败）、HTTP 状态码 429/5xx - 用
errors.As判断底层错误类型，比字符串匹配更可靠：var netErr net.Error; errors.As(err, &netErr) && netErr.Timeout() - 别忽略
context.Canceled和context.DeadlineExceeded：它们意味着调用方已放弃，此时应立即返回，不再重试 - 如果依赖下游服务返回
Retry-Afterheader，需在重试函数中解析并动态设置下一次间隔，这时得换用backoff.WithDelayFunc自定义退避逻辑
真正难的不是写重试代码，而是判断“这次失败到底是不是暂时的”。网络层错误相对明确，但业务状态码的语义得结合接口文档逐个确认，这里最容易被跳过。
