在分布式系统里，Web请求因为网络闪断、服务重启或限流而偶发失败是常态。Golang的net/http包只负责发出请求和接收响应，本身没有提供任何自动重试能力，如果业务直接把单次请求结果当作最终结论，很容易因为瞬时错误导致整体功能异常。因此在客户端层面实现一套清晰的请求重试与容错策略，是提升服务稳定性的基础工作。
重试策略的核心参数与设计原则
实现Web请求重试前，必须先明确几个关键参数：最大重试次数、重试间隔算法、超时边界以及哪些错误才值得重试。最大重试次数通常设为三到五次，过多会放大故障影响面，过少则无法覆盖短暂抖动。重试间隔如果固定为相同秒数，大量客户端会在同一时刻再次请求，形成重试风暴，因此更合理的是采用指数退避并叠加随机偏移。
另一个常被忽略的点是错误分类。DNS解析失败、连接被拒绝、上下文超时属于可重试的网络层错误；而返回状态码为400、401、403这类业务语义明确的响应，重试没有意义。我们在封装客户端时应先判断错误类型或状态码，再决定是否进入重试逻辑，避免对不可逆请求做无效重复调用。
幂等性也是设计容错时必须考虑的前提。GET、PUT、DELETE在标准语义下具备幂等特征，重试相对安全；POST创建资源如果服务端没有去重机制，重试可能导致重复数据。开发者需要在代码层面对非幂等调用做特殊标记，或者改用支持幂等键的请求头，才能放心开启自动重试。
基于指数退避与Jitter的代码示例
下面展示一个使用context控制生命周期、并带指数退避和随机jitter的GET请求重试封装。该实现通过循环递减剩余重试次数，在每次失败后对当前间隔乘二并加上随机毫秒，避免客户端同步冲击服务端。
代码中使用了time.Duration来表示退避时间，并用math/rand生成偏移量。注意我们把整体超时交给了context.WithTimeout，这样即便重试多次，也不会超过业务设定的最长时间。如下方示例，每次重试前都会先检查ctx.Err()，一旦父上下文取消就立即返回。
package main
import (
"context"
"fmt"
"io"
"math/rand"
"net/http"
"time"
)
func retryGet(ctx context.Context, url string, maxRetry int) ([]byte, error) {
var body []byte
backoff := 100 * time.Millisecond
for i := 0; i <= maxRetry; i++ {
if ctx.Err() != nil {
return nil, ctx.Err()
}
req, _ := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
resp, err := http.DefaultClient.Do(req)
if err == nil && resp.StatusCode == http.StatusOK {
defer resp.Body.Close()
body, _ = io.ReadAll(resp.Body)
return body, nil
}
if resp != nil {
resp.Body.Close()
}
if i == maxRetry {
break
}
jitter := time.Duration(rand.Intn(100)) * time.Millisecond
select {
case <-time.After(backoff + jitter):
case <-ctx.Done():
return nil, ctx.Err()
}
backoff = backoff * 2
}
return nil, fmt.Errorf("request failed after %d retries", maxRetry)
}
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
data, err := retryGet(ctx, "http://127.0.0.1:8080/api", 3)
if err != nil {
fmt.Println("error:", err)
return
}
fmt.Println("data:", string(data))
}
上述实现虽然简单，但已经覆盖了重试次数、退避、上下文取消等要素。如果需要在生产环境使用，建议将http.DefaultClient替换为配置了Transport和Timeout的自定义客户端，并增加针对状态码的白名单判断，例如只对502、503、504进行重试。
此外，随机jitter的范围不宜过大，否则在调试时难以预期行为；也不宜过小，否则退避效果不明显。一般取基础间隔的零到五十百分比作为偏移即可。通过压测观察服务在依赖方抖动时的成功率，可以反推最合适的maxRetry与初始backoff组合。
结合熔断器与超时控制的综合容错方案
单纯重试并不能解决下游长期不可用的问题。当后端持续报错时，频繁重试只会消耗本端资源并拉长调用链耗时。此时应引入熔断器模式，在错误率超过阈值后直接拒绝请求，经过冷却时间再尝试半开恢复。Golang中可借助gobreaker等库，也可自行用原子计数维护状态机。
超时控制则是另一道保险。每个Web请求都应绑定context截止时间，重试逻辑里的单次请求超时应当小于总上下文超时，否则可能出现最后一次重试永远无法执行完的尴尬。我们可以在创建http.Client时设置Timeout字段，或者在NewRequestWithContext中传入更短的子上下文，实现层层约束。
综合来看，一个健壮的Golang Web容错层通常由三层组成：最底层是带重试和退避的HTTP客户端，中间层是熔断与降级开关，最上层是业务调用的超时与兜底数据。三者配合才能让系统在部分依赖异常时仍维持核心链路可用，而不是被单次网络失败拖垮整个请求线程。
常见误区与调试建议
不少人在写重试时会用for循环包裹整个函数，却忘记在循环内重建请求体，导致第二次发送时流已关闭而报空。对于带body的POST请求，每次重试都应重新生成bytes.Reader或strings.NewReader，保证请求体可被重复读取。同时要避免在重试函数里吞掉原始错误，应至少用日志或wrap方式保留错误链。
调试阶段可以故意将依赖服务返回503，并打开Golang的GODEBUG=http2debug=2或借助代理工具查看重试间隔是否如预期递增。若发现重试过于密集，应检查jitter生成逻辑是否被正确执行，以及上下文超时是否过宽。通过单元测试注入不同错误类型，也能验证分类重试逻辑的准确性。
最后提醒，重试策略不是越多越好。在网关或反向代理已经具备重试能力的场景下，后端服务再叠加重试会产生乘数效应。团队内部需要约定好哪一层负责重试，通常建议由最靠近故障源的调用方做有限次重试，更上游只做熔断与降级，这样整体系统的故障传播才可控。