Go 重试循环为什么会越跑越慢：用 timer.Reset 控制退避与取消

订单服务调用库存接口时，偶发的 503 本来只需要重试两次，结果压测一上来，重试器本身开始制造额外延迟：请求越多，等待越不稳定，取消信号也要等一轮才被看到。问题通常不在“要不要重试”，而在等待实现把每轮都当成一次临时事件处理，既没有复用定时器，也没有给退避时间设置边界。

先把重试任务拆成“结果、等待、取消”三件事

重试器最容易写成一个很短的循环：调用失败，time.After 等一会儿，再调用一次。短代码不等于边界清楚。库存接口返回 503 时，真正要判断的是这次失败是否暂时、还剩多少尝试次数，以及调用方是否已经不再等待这个结果。

这个拆分也决定了接口形状：业务函数负责一次调用，重试器负责节奏和取消，判定函数负责告诉重试器“这类错误值不值得再试”。

为什么循环里的 time.After 会让等待变得难控

下面的写法看起来直观，但每次进入等待分支都会创建一个新的计时通道：

for attempt := 1; attempt 

time.After 并不是错误 API，少量调用完全可以用。问题出现在高并发和长退避场景：等待中的请求会各自持有计时器，退避策略又常常没有上限；当上游恢复时，大量请求可能在相近时间一起醒来，形成第二次流量尖峰。这里别急着只把等待时间调短，先把计时器生命周期和退避边界写清楚。

用 timer.Reset 写一个可取消的退避等待

把定时器放在循环外复用，等待动作集中到一个小函数里。Stop 和排空旧通道是为了处理定时器已经触发但还没被当前分支消费的情况，避免下一轮一进入就立即返回。

func waitBackoff(ctx context.Context, timer *time.Timer, delay time.Duration) error {
    if !timer.Stop() {
        select {
        case 

这里的关键不是“把 time.After 换成另一个 API”，而是让每一轮等待都有明确的开始和结束：开始前清理旧状态，结束时只返回成功等待或取消。调用方不需要知道定时器细节。

退避要有上限，还要加入轻微抖动

简单的指数退避可以写成 base * 2^(attempt-1)，但线上通常还要夹一个最大间隔：

func backoff(attempt int, base, cap time.Duration, jitter time.Duration) time.Duration {
    delay := base
    for i := 1; i  cap/2 {
            delay = cap
            break
        }
        delay *= 2
    }
    if delay > cap {
        delay = cap
    }
    if jitter > 0 {
        delay += time.Duration(rand.Int63n(int64(jitter)))
    }
    if delay > cap {
        return cap
    }
    return delay
}

抖动不需要很大，重点是别让同一批请求共享完全相同的醒来时刻。若上游有明确的 Retry-After，应先校验它的范围，再决定是否覆盖本地退避，不能无条件相信外部返回值。

把一次调用和重试规则组合起来

下面的 Retry 只关心控制流，业务代码可以传入自己的调用函数和临时错误判定。这样做的好处是：库存、支付、配置中心各自有不同的重试边界，但取消、计时器和最大间隔不会各写一套。

func Retry(ctx context.Context, maxAttempts int, base, cap time.Duration,
    call func(context.Context) error, temporary func(error) bool) error {
    if maxAttempts 

一次调用内部仍然必须使用同一个 ctx。如果业务函数自己忽略取消，外层等待虽然能结束，正在执行的网络操作却可能继续占用连接；所以重试器不能替代 HTTP 客户端或数据库驱动的取消支持。

每次改动后，用日志和测试确认节奏真的变了

不要只看最终成功率。至少记录请求标识、尝试序号、退避时长和错误类型，检查失败是否集中发生在同一毫秒窗口。单元测试则要覆盖成功首轮、连续临时失败、永久失败、上下文取消和达到最大次数这五条路径。

func TestRetryStopsWhenContextCanceled(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    calls := 0
    err := Retry(ctx, 5, time.Millisecond, 20*time.Millisecond,
        func(context.Context) error {
            calls++
            if calls == 1 {
                cancel()
            }
            return errors.New("temporary upstream failure")
        }, func(error) bool { return true })

    if !errors.Is(err, context.Canceled) {
        t.Fatalf("want cancellation, got %v", err)
    }
    if calls != 1 {
        t.Fatalf("want one call, got %d", calls)
    }
}

压测时重点看请求总数、上游 5xx、重试次数、取消延迟和 goroutine 数量。只有把这些指标放在同一时间线上，才能区分“上游恢复了”和“客户端只是把失败推迟了”。

常见问题：哪些错误不应该重试

HTTP 400 和参数校验失败要不要重试？

通常不要。请求内容不变时，再发一次只会重复消耗资源；应返回参数错误并修正调用方。

重试次数设置得越多越安全吗？

不是。次数、总耗时和单次退避要一起设上限，幂等性不明确的写操作尤其要谨慎。

context.WithTimeout 能不能替代最大重试次数？

不能。超时限制总等待时间，次数限制调用次数，两者叠加才能避免短调用在极短退避下发送过多请求。

把重试器当成有边界的调用组件

重试不是给失败加一个循环，而是给一次调用补上明确的停止条件：只重试暂时性错误，退避有最大值，等待能响应取消，调用次数可观察。少量脚本用 time.After 没问题；服务热路径则更适合复用 time.Timer，把生命周期写在代码里，后续排查才有证据可看。