如何在Golang中实现请求重试_重试机制设计方法

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 }

重试机制真正难的不是代码长度，而是判断边界：什么错误值得重试、重试后是否掩盖了业务逻辑缺陷、超时时间与重试次数如何协同。很多线上问题其实是重试放大了雪崩——比如下游已慢到超时，上游还在不断重试，进一步压垮对方。留出可观测入口（记录每次重试原因、耗时、状态码）比实现本身更重要。