Go中time.Sleep做指数退避易卡死协程，因裸睡阻塞goroutine；应结合context取消、超时控制，用backoff.Retry或retryablehttp.Client，设合理基础时间、最大次数、jitter及退避上限。
Go 里用 time.Sleep 做指数退避容易卡死协程？
不是 time.Sleep 本身有问题，而是直接裸睡会阻塞当前 goroutine，如果在 HTTP 客户端、消息消费循环这类长期运行的逻辑里硬套 time.Sleep，可能让整个 worker 协程停摆，甚至拖垮连接池或超时控制。
正确做法是把退避逻辑和上下文取消、超时控制绑在一起。别自己写 for + sleep，优先用 backoff.Retry（来自 github.com/cenkalti/backoff/v4）或者标准库组合 time.AfterFunc + context.WithTimeout。
- 每次重试前用
select等待time.After(2^attempt * base)或backoff.NextBackOff()，同时监听ctx.Done() - 基础退避时间建议设为
100 * time.Millisecond，最大尝试次数别超过 5–6 次，否则退避时间可能长达数秒，用户感知明显 - 注意：某些老版本
backoff包默认不 jitter，线上突增重试可能引发雪崩，务必启用backoff.WithJitter()
HTTP 请求失败后怎么嵌入指数退避而不污染业务代码？
别在每个 http.Do 外面手写 retry 循环。把退避逻辑下沉到 transport 层或封装成独立 client，让业务调用看起来和普通请求一样。
推荐用 retryablehttp.Client（github.com/hashicorp/go-retryablehttp），它原生支持指数退避、jitter、状态码过滤，且保留了 http.Client 的所有行为（如 redirect、cookiejar）。
立即学习“go语言免费学习笔记（深入）”；
- 设置
Client.RetryMax控制最大重试次数，Client.RetryWaitMin/RetryWaitMax控制退避区间 - 用
Client.CheckRetry自定义重试条件，比如只对502、503、504和网络错误重试，跳过400、401等客户端错误 - 注意：默认不重试 POST，因为非幂等；若确定接口幂等，需显式覆盖
DefaultRetryPolicy
context.DeadlineExceeded 和退避冲突怎么办？
常见错误是给整个重试过程设一个短 deadline，比如 500ms，但退避策略本身需要多次尝试，总耗时很容易超限——结果第一次失败后还没来得及退避就直接返回 context.DeadlineExceeded。
必须分层控制超时：外层 context 控制“整体截止时间”，内层用独立 timeout 控制单次请求，退避时间只占其中一部分。
- 单次请求 timeout 建议设为
200 * time.Millisecond，退避从50ms起步，这样即使重试 3 次，总耗时也大概率压在 500ms 内 - 不要用
context.WithDeadline直接包住整个 retry 循环；改用context.WithTimeout(ctx, singleReqTimeout)包每一轮 - 如果上游服务 SLA 是 200ms P99，你的退避上限（max backoff）就不该超过 100ms，否则最后一次重试大概率失败
自定义退避函数时为什么 math.Exp 不要直接用？
math.Exp(float64(attempt)) 看起来“更数学”，但实际会导致退避增长过快：第 5 次重试就是 e⁵ ≈ 148 秒，完全失去可用性。生产环境几乎没人这么用。
真实项目中，99% 场景用的是 “乘法退避”：base * (2 ^ attempt)，再叠加 jitter 防止重试风暴。Golang 标准库里没有现成的 ExpBackoff 函数，得自己算。
- 用
time.Duration(float64(base) * math.Pow(2, float64(attempt)))，注意base单位是 nanosecond，别传100当毫秒用 - jitter 推荐加 ±25%，即
rand.Float64()*0.5 - 0.25，避免所有实例在同一时刻发起重试 - 退避上限必须硬限制，比如
min(calculated, 5*time.Second)，否则网络抖动时可能退避几十秒，业务不可接受
退避不是越“智能”越好，关键是可控、可预测、不放大故障。真正难的不是算时间，而是判断哪类错误值得重试、重试几次、以及重试失败后是否该降级或告警——这些逻辑往往比退避公式本身更影响高可用效果。
