如何在Golang服务中接入Go-retryablehttp弹性重试-Golang-PHP中文网

retryablehttp.NewClient() 默认配置不能直接上生产，因其默认不重试429/408、不处理非幂等请求体重放、不感知context取消、RetryMax=4实为总尝试次数（含首次）、退避间隔过于激进且无抖动，易导致线上雪崩或资源泄漏。

如何在golang服务中接入go-retryablehttp弹性重试

直接用 retryablehttp.NewClient() 启动就跑不起来——它默认不重试 429、不处理非幂等请求体、不感知 context 取消，线上一压就出问题。

为什么 NewClient() 默认配置不能直接上生产

默认的 retryablehttp.NewClient() 看似开箱即用，但几个关键行为和线上需求严重错位：

默认只对网络错误（如 net.OpError）和 5xx 响应重试，**完全忽略 429 Too Many Requests 和 408 Request Timeout** —— 这两类在限流/网关场景下极常见，不重试等于放弃弹性
所有请求都尝试重放 req.Body，但若你传的是 strings.NewReader("...") 或未克隆的原始 *http.Request，第二次重试时 Body.Read 直接返回 EOF，导致 panic 或空请求体
整个重试过程**不接收 context.Context**，一旦上级调用超时或取消，重试 goroutine 仍会继续 sleep 并发起请求，造成资源泄漏和下游误压
RetryMax = 4 是总尝试次数（1 次原请求 + 3 次重试），但很多人误以为是“最多重试 4 次”，结果容错能力被砍掉一轮

必须重写 CheckRetry：精准控制哪些响应/错误可重试

CheckRetry 是决定是否重试的唯一开关，不覆盖它，就等于把判断权交给库的硬编码逻辑（它连 429 都不认）。

正确做法是自己实现一个白名单判断函数：

client.CheckRetry = func(ctx context.Context, resp *http.Response, err error) (bool, error) {
    if err != nil {
        var opErr *net.OpError
        if errors.As(err, &opErr) && (opErr.Err == context.DeadlineExceeded || strings.Contains(opErr.Err.Error(), "timeout")) {
            return true, nil // 超时类网络错误重试
        }
        if urlErr, ok := err.(*url.Error); ok && urlErr.Timeout() {
            return true, nil
        }
        return false, retryablehttp.Permanent(err) // 其他网络错误（如 DNS 失败）也建议重试，但需结合业务判断
    }
<pre class="brush:php;toolbar:false;">// 显式检查状态码
switch resp.StatusCode {
case 408, 429:
    return true, nil // 明确加入 408/429
case 500, 502, 503, 504:
    // 丢弃响应体，避免连接复用失败
    io.Copy(io.Discard, resp.Body)
    resp.Body.Close()
    return true, nil
default:
    return false, retryablehttp.Permanent(fmt.Errorf("HTTP %d", resp.StatusCode))
}

}

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

别用 strings.Contains(err.Error(), "timeout") 模糊匹配——url.Error.Timeout() 和 context.DeadlineExceeded 才是可靠信号
每次判定为可重试后，**必须手动 io.Copy(io.Discard, resp.Body) 再 resp.Body.Close()**，否则底层 TCP 连接无法复用，后续请求可能卡住
对 4xx 返回 retryablehttp.Permanent(err)，强制终止重试循环；不要返回 false, nil，那会导致静默失败

必须用 req.WithContext() + 每次重试新建 request

retryablehttp 不自动透传 context，也不自动克隆 request。如果你复用同一个 *http.Request 实例，第二轮重试时 req.Body 已被读空，Do() 会发一个 body 为 nil 的请求。

每次调用 Do() 前，必须基于原始 request 创建新实例：req = req.WithContext(ctx)（注意不是 req.Clone(ctx)，Clone 不处理 Body 重放）
如果原始请求带 body（如 POST JSON），确保 body 来源支持多次读取：用 bytes.NewBuffer(bodyBytes) 替代 strings.NewReader(string(bodyBytes))；或者提前把 body 内容缓存为 []byte，每次 new request 时重新构造
不要在 client 初始化时设置全局 Timeout，而应在每个 request 的 context 上设：ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)，然后 req = req.WithContext(ctx)

退避策略要显式构造，别信默认值

默认的 RetryWaitMin = 1s / RetryWaitMax = 30s 对大多数微服务来说太激进——1 秒内重试可能还没等下游恢复，30 秒等待又让调用链超时雪崩。

推荐起始间隔 100ms，最大间隔 2s，总重试耗时控制在 5s 内：client.RetryWaitMin = 100 * time.Millisecond，client.RetryWaitMax = 2 * time.Second
指数退避本身没抖动（jitter），多个实例可能在同一毫秒发起重试，形成“重试风暴”。库不提供 jitter 封装，得自己加：time.Sleep(time.Duration(rand.Int63n(int64(client.RetryWaitMin))) + client.RetryWaitMin)，或改用 backoff/v4 配合 retryablehttp
RetryMax = 4 表示最多尝试 4 次（含首次），若你希望「最多重试 3 次」，就得设成 4；若设成 3，实际只有 2 次重试机会