不能只用 time.Sleep 硬等，因其会阻塞 goroutine、无法响应取消或超时，且易引发重试风暴；必须结合 context.Context 实现可取消、带退避与抖动的重试。
为什么不能只用 time.Sleep 硬等？
直接在 for 循环里写 time.Sleep(1 * time.Second) 看似简单，但会卡死 goroutine、无法响应取消或超时——比如用户已关闭页面，你的重试还在傻等 3 秒。更糟的是，所有客户端在同一秒重试，下游服务瞬间被打爆（“重试风暴”）。
- 必须把
context.Context作为第一参数传入重试函数，并在每次循环开头用select检查ctx.Done() - 底层调用（如
http.Client.Do、grpc.Invoke）也要透传ctx，否则单次请求超时了，重试还在继续 - 别在重试函数里自己调
context.WithTimeout——总超时应由调用方统一控制
retryWithBackoff 函数怎么写才真正可用？
一个生产级重试函数得同时处理退避、抖动、错误分类和上下文。下面这个精简版可直接抄用（注意初始化随机源）：
func retryWithBackoff(ctx context.Context, maxRetries int, baseDelay time.Duration, fn func() error) error {
// 生产环境务必用独立 rand.Rand，避免多 goroutine 共享 seed 导致抖动失效
r := rand.New(rand.NewSource(time.Now().UnixNano()))
<pre class='brush:php;toolbar:false;'>var err error
for i := 0; i <= maxRetries; i++ {
select {
case <-ctx.Done():
return ctx.Err()
default:
}
err = fn()
if err == nil {
return nil
}
// 只对临时性错误重试：网络超时、连接拒绝、gRPC Unavailable/DeadlineExceeded 等
if !isRetryable(err) {
return err
}
if i < maxRetries { // 最后一次失败不 sleep，直接返回错误
// 指数退避：baseDelay * 2^i
backoff := baseDelay * time.Duration(1<<uint(i))
// 抖动：±50% 范围内随机，上限不超过 0.5 * backoff
jitter := time.Duration(r.Float64() * 0.5 * float64(backoff))
time.Sleep(backoff + jitter)
}
}
return err}
-
maxRetries = 3是常见合理值（含首次尝试共 4 次），再失败就该告警而非硬扛 -
baseDelay推荐从100ms或250ms起步，避免首重试过快冲击下游 -
isRetryable必须自己实现：对*url.Error判断Timeout()，对 gRPC 错误用status.Code()检查是否为codes.Unavailable
HTTP 请求重试最容易踩的三个坑
HTTP 是重试最常见场景，但也是坑最多的地方——状态码、重定向、连接复用都影响重试决策。
- 别盲目重试所有 4xx：只有
429 Too Many Requests和部分408 Request Timeout可重试，400/401/404直接返回 - 别忽略
resp.Body：若第一次请求已读 body，重试时需重新构造 request（body 可能不可复用） - 别让
http.Client的Timeout和重试总超时冲突：设client.Timeout = 0，靠外层context.WithTimeout统一控时
要不要封装成选项模式（functional options）？
如果项目里重试逻辑散落在 5 个地方，且参数各不相同（有的要 2 次、有的要 500ms 基础延迟、有的要跳过抖动），那就值得抽成 DoWithRetry(ctx, fn, WithMaxRetries(3), WithBackoff(200*time.Millisecond)) 这种形式。
但小项目或单点调用，硬编码参数反而更清晰。真正关键的不是封装多漂亮，而是：每次重试前是否检查了 ctx.Err()、是否做了错误分类、抖动是否用了独立 rand.Rand——这三个点漏掉任意一个，重试就只是“看起来优雅”的定时炸弹。
