Go中实现指数退避需加随机抖动（jitter），公式为base×(2^attempt)×jitter（jitter∈[0.5,1.5)），并限制最大重试次数、隔离每个请求的退避状态，避免共享实例导致计数错乱。
Go 里用 time.Sleep 实现指数退避，别直接写死倍数
指数退避不是简单地每次 sleep 2 倍时间，必须加随机抖动（jitter），否则大量请求会在同一时刻重试，击穿下游。Go 标准库不提供开箱即用的退避封装，得自己组合 time.Sleep 和 rand.Float64。
- 基础公式是：
base * (2^attempt) * jitter，其中jitter通常取 [0.5, 1.5) 区间随机值 -
base别设太小（比如 10ms），也别太大（比如 1s）；常见起始值是100 * time.Millisecond - 最大尝试次数建议硬限制，比如 5～8 次，避免无限卡住；超过后应直接返回错误，而不是继续等
- 注意：在测试中禁用真实 sleep，用
func() time.Duration注入延迟逻辑，方便 mock
用 backoff.Retry 配合自定义策略，比手写更稳
第三方库 github.com/cenkalti/backoff/v4 是 Go 社区事实标准，它把抖动、最大重试、上下文取消都封装好了，但默认策略不够灵活——你得自己构造 backoff.BackOff 实例。
- 别直接用
backoff.NewExponentialBackOff()，它默认 base=100ms、max=10s、maxInterval=1s，容易误判超时 - 务必调用
.WithContext(ctx, err)，否则重试会忽略context.Context的 deadline 或 cancel - 如果重试逻辑里有 HTTP 调用，记得把原始
*http.Request的ctx替换为带 timeout 的新 context，否则底层连接可能不响应取消 - 示例关键行：
backoff.WithContext(backoff.WithMaxRetries(b, 5), ctx)
重试时别忽略错误类型，net.OpError 和 context.DeadlineExceeded 处理方式不同
不是所有错误都适合重试。盲目 retry 会导致雪球效应，比如下游已 503，你反复发请求只会加重负载。
-
net.OpError（如 connection refused、timeout）通常可重试；但net/http.ErrHandlerTimeout属于服务端超时，不应重试 -
context.DeadlineExceeded表示本次调用已超时，再 retry 就是另一次新请求，需重置计时器，不能沿用旧 context - 对 HTTP 状态码要显式判断：
400类错误（如400 Bad Request）基本不可重试；429 Too Many Requests可重试，但应优先读取Retry-Afterheader - 建议封装一个
shouldRetry(err error) bool函数，把判断逻辑收口，避免散落在各处
并发场景下共享退避状态会出问题，每个请求必须独立初始化
如果多个 goroutine 共用同一个 backoff.BackOff 实例，NextBackOff() 返回的时间会错乱，因为内部维护了 attempt 计数器——这是最隐蔽也最容易被忽略的坑。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要把
backoff.BackOff当成全局变量或单例复用 - 每次发起重试前，都应调用
backoff.NewExponentialBackOff()或b.Clone()（v4 版本支持）生成新实例 - 如果用了自定义结构体封装重试逻辑，确保
Reset()在每次 retry 开始前被调用，否则 attempt 从上次残留值继续累加 - 在 HTTP 客户端中间件里尤其要注意：每个
*http.Request对应的重试必须隔离状态
真正难的不是算出下一个 sleep 时间，而是判断「这次到底该不该 retry」，以及「retry 的边界在哪里」——网络错误、业务错误、限流响应、客户端超时，每种情况的语义完全不同，混在一起处理迟早出事。
