Go语言实现HTTP请求重试工具封装方法

最简重试逻辑需用 net/http + time.Sleep 实现：捕获超时、连接类错误重试，4xx 错误不重试；用 context.WithTimeout 控制单次超时；每次重试前 sleep 并指数退避；每次新建 *http.Request。

用 net/http + time.Sleep 实现最简重试逻辑

Go 标准库不自带 HTTP 重试，得自己套一层循环。核心是捕获 error 并判断是否值得重试，而不是无脑重试所有失败。

常见错误现象：Get "https://api.example.com": context deadline exceeded、connection refused、Client.Timeout exceeded —— 这些适合重试；而 401 Unauthorized 或 404 Not Found 一般不该重试。

• 用 context.WithTimeout 控制单次请求超时，别依赖 http.Client.Timeout 全局设死
• 重试前必须 time.Sleep，否则可能瞬间打爆下游；推荐从 100ms 开始指数退避（如 100ms → 200ms → 400ms）
• 别在循环里复用同一个 *http.Request：它内部带 body 和 context，第二次调用会报 http: Request.Body is nil

示例关键片段：

for i := 0; i < maxRetries; i++ {
    req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    resp, err := client.Do(req)
    if err == nil && resp.StatusCode < 500 {
        return resp, nil
    }
    if i < maxRetries-1 {
        time.Sleep(time.Duration(100*math.Pow(2, float64(i))) * time.Millisecond)
    }
}

封装成可复用的 RetryClient 类型时要注意什么

直接写函数也能用，但多人协作或项目变大后，封装成结构体更可控。重点不是“怎么定义 struct”，而是字段设计是否暴露了不该暴露的细节。

使用场景：需要统一控制重试次数、退避策略、错误过滤规则，且不同 API 调用需差异化配置（比如文件上传不重试 500，但查询接口要重试）。

• MaxRetries 建议设为 3～5，默认 3；设太大容易掩盖真实故障
• 别把 http.Client 嵌入结构体并导出——外部修改其 Transport 或 Timeout 会破坏重试语义；应该只暴露 Do() 方法
• 加一个 ShouldRetry 函数字段，类型为 func(*http.Response, error) bool，比硬编码判断更灵活
• 避免在 Do() 内部 new http.Client：连接复用失效，CPU 和 fd 消耗陡增

为什么不用第三方库如 backoff 或 retryablehttp

这些库功能全，但引入后常带来两个隐性成本：依赖版本冲突、默认行为不符合业务预期（比如自动重试 5xx 且不区分 500/503）。

性能影响：标准库 net/http 已经足够快，第三方封装如果在每次重试都新建 http.Client 或滥用 sync.Pool，反而降低吞吐。

• backoff.Retry 默认用 ExponentialBackOff，但它的初始间隔是 100ms，最大间隔 1s —— 对内网服务可能太保守，对海外 API 又可能太激进
• retryablehttp 的 CheckRetry 回调接收 *http.Response，但首次请求失败时 resp 是 nil，容易 panic，得手动判空
• 如果你只需要「失败后等 200ms 再试一次」，写 10 行代码比配 5 个回调更可靠

重试时最容易被忽略的副作用

HTTP 方法语义不是装饰：对 POST / PUT / DELETE 盲目重试，可能造成重复下单、库存扣双倍、资源删两次。

兼容性影响：有些老服务不支持 idempotency-key 头，也没实现幂等逻辑，此时重试等于制造数据异常。

• GET / HEAD 请求天然幂等，可放心重试；其他方法必须先确认服务端是否支持幂等（看文档或加 X-Idempotency-Key）
• 如果请求带 body（如 JSON），重试前要确保 req.Body 可重读 —— 用 bytes.NewReader 包一层原始数据，别传 strings.NewReader 后反复用
• 日志里务必打出重试次数和原始错误，否则线上出问题时分不清是第几次失败，还是根本没走重试逻辑

真正难的从来不是“怎么加重试”，而是“哪些请求能重试、重试几次、等多久、失败后怎么兜底”。这些决策没法靠工具自动做，得贴着业务逻辑写。