Go中http.Client默认不重试，需自定义RoundTripper实现：重试前重建Body、区分可重试错误（如timeout）、设最大次数（如3次）和指数退避。
Go 里没有内置的请求重试逻辑，http.Client 默认只做一次尝试；要实现可靠重试，必须自己封装或借助成熟库（如 github.com/hashicorp/go-retryablehttp），但核心控制点始终在「何时重试」「重试几次」「间隔怎么算」「哪些错误可重试」。
用 http.Client + 自定义 RoundTripper 实现基础重试
直接改写 http.Transport 的行为太重，更轻量的做法是包装 RoundTripper，在 RoundTrip 方法里做循环重试。关键不是“重发请求”，而是“重发 *同一请求实例*”——注意不要意外修改 *http.Request 的 Body（它是一次性读取的）。
- 必须在每次重试前重建
Body：如果原始请求带io.Reader，需提前缓存为[]byte或用bytes.NewReader重新构造 - 跳过不可重试的错误：比如
url.Error中的timeout、connection refused可重试，但400 Bad Request或401 Unauthorized通常不该重试 - 避免无限重试：建议硬限制最大次数（如
maxRetries := 3），并用指数退避（time.Sleep(time.Second ）控制节奏
github.com/hashicorp/go-retryablehttp 的典型误用点
这个库封装得较完善，但新手常掉进几个坑：
- 忘记设置
RetryMax：默认是0（即不重试），必须显式赋值，例如client.RetryMax = 3 - 误以为所有 HTTP 状态码都会重试：默认只对
5xx和连接类错误重试，429 Too Many Requests需手动加到RetryableClient.CheckRetry函数里 - 忽略上下文取消：如果外层
context.Context已取消，重试逻辑仍可能继续跑完全部次数——应在每次重试前检查ctx.Err() != nil - 自定义
Backoff时传错单位：该函数返回的是time.Duration，但容易误传毫秒数而没调用time.Millisecond
重试时如何安全处理请求体（Body）
HTTP 请求体是流式读取的，一旦被 http.Transport 消费过，再次调用 req.Body.Read() 就会返回 io.EOF。重试前必须能“重播”原始内容。
立即学习“go语言免费学习笔记（深入）”；
- 若原始 Body 是
strings.NewReader或bytes.NewReader，可直接重复使用（它们支持多次读） - 若来自文件或网络流，必须提前读入内存：
bodyBytes, _ := io.ReadAll(req.Body); req.Body = io.NopCloser(bytes.NewReader(bodyBytes)) - 更稳妥的做法是把原始 payload 存为字段（如
payload []byte），每次重试都新建bytes.NewReader(payload)赋给req.Body - 注意内存开销：大文件上传场景下，全量缓存 body 不现实，此时应改用支持断点续传的协议，而非依赖 HTTP 重试
func retryDo(ctx context.Context, req *http.Request, maxRetries int) (*http.Response, error) {
var resp *http.Response
var err error
for i := 0; i <= maxRetries; i++ {
if ctx.Err() != nil {
return nil, ctx.Err()
}
resp, err = http.DefaultClient.Do(req)
if err == nil && resp.StatusCode >= 200 && resp.StatusCode < 300 {
return resp, nil
}
if i == maxRetries {
break
}
time.Sleep(time.Second << uint(i)) // 指数退避
}
return resp, err
}
重试机制真正难的不是代码长度，而是判断边界：什么错误值得重试、重试后是否掩盖了业务逻辑缺陷、超时时间与重试次数如何协同。很多线上问题其实是重试放大了雪崩——比如下游已慢到超时，上游还在不断重试，进一步压垮对方。留出可观测入口（记录每次重试原因、耗时、状态码）比实现本身更重要。
