直接用 time.Sleep 做重试会失败，因其无法错峰、缺乏随机性，易撞上持续抖动窗口、触发限流并引发重试风暴；需用指数退避（含基础间隔、倍数、jitter）配合上下文取消和时间上限。
为什么直接用 time.Sleep 做重试会失败
临时网络抖动（比如 DNS 超时、TLS 握手失败、HTTP 503）往往在几毫秒到几百毫秒内自行恢复，但固定间隔重试（如每次 time.Sleep(100 * time.Millisecond)）容易撞上持续抖动窗口，甚至触发服务端限流。更糟的是，多个协程同时退避会形成“重试风暴”，把下游压垮。
指数退避的核心不是“多等一会儿”，而是让重试分布变稀疏、错峰、带随机性——这需要三要素：基础间隔、退避倍数、抖动（jitter）。
-
baseDelay通常设为 10–100ms，太小起不到错峰作用，太大拖慢成功路径 - 倍数一般用 2（即 10ms → 20ms → 40ms → 80ms…），超过 3 容易退得太慢
- 必须加 jitter（推荐 0.3–0.5 的随机因子），否则所有请求会在同一时刻重试
用 backoff.Retry 配合 backoff.WithMaxRetries 最简落地
社区最常用的是 github.com/cenkalti/backoff/v4，它封装了 jitter、最大重试次数、上下文取消等细节，不用自己算时间。
典型用法：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
import "github.com/cenkalti/backoff/v4"
<p>func callWithBackoff() error {
b := backoff.WithMaxRetries(backoff.NewExponentialBackOff(), 5)
return backoff.Retry(operation, b)
}</p><p>func operation() error {
resp, err := http.DefaultClient.Do(req)
if err != nil {
return backoff.Permanent(err) // 永不重试的错误，如参数错
}
if resp.StatusCode >= 400 && resp.StatusCode < 500 {
return backoff.Permanent(fmt.Errorf("client error: %d", resp.StatusCode))
}
if resp.StatusCode >= 500 {
return fmt.Errorf("server error: %d", resp.StatusCode) // 触发重试
}
return nil
}
-
backoff.NewExponentialBackOff()默认 base=100ms，max=10s，cap=1s，已含 jitter -
backoff.Permanent()标记不该重试的错误（如 4xx、JSON 解析失败），避免无限循环 - 返回非
backoff.Permanent错误才重试；返回nil表示成功
backoff.ExponentialBackOff 的关键字段和常见调优点
默认配置适合通用 HTTP 调用，但实际场景常需调整。直接改结构体字段比写新 backoff 实现更安全：
b := backoff.NewExponentialBackOff() b.InitialInterval = 50 * time.Millisecond b.MaxInterval = 2 * time.Second b.MaxElapsedTime = 10 * time.Second // 总耗时上限，超时后不再重试 b.Multiplier = 2.0
-
MaxElapsedTime比MaxRetries更可靠：网络抖动可能集中在某几秒，固定次数容易过早放弃或过度重试 -
MaxInterval建议设为 1–3 秒，再大对“临时”抖动意义不大，反而拉长失败感知 - 不要动
RandomizationFactor（默认 0.5）：它控制 jitter 幅度，改小会导致重试集中，改大会让退避过松散
自定义 backoff 函数时最容易漏掉的两个细节
有人图省事手写 for + sleep，但以下两点几乎必踩坑：
- 没检查
context.Done()：重试中收到 cancel 或 timeout 后应立即退出，否则 goroutine 泄露 - 退避时间没做上限截断：第 10 次重试若按 2^10 × 100ms 算是 102.4 秒，远超业务容忍——必须用
min(计算值, MaxInterval)
一个最小可用的手写版本（不推荐生产，仅说明逻辑）：
func retryWithBackoff(ctx context.Context, op func() error, maxTries int) error {
var err error
for i := 0; i < maxTries; i++ {
select {
case <-ctx.Done():
return ctx.Err()
default:
}
if err = op(); err == nil {
return nil
}
if i == maxTries-1 {
break
}
delay := time.Duration(float64(100*time.Millisecond) * math.Pow(2, float64(i)))
delay = min(delay, 2*time.Second)
delay = time.Duration(float64(delay) * (0.5 + 0.5*rand.Float64())) // jitter
select {
case <-time.After(delay):
case <-ctx.Done():
return ctx.Err()
}
}
return err
}
真正上线前，优先用 backoff/v4，它已处理了信号中断、timer 复用、goroutine 安全等边界情况。自己实现时，jitter 计算和上下文传播是最容易出错的两处。
