必须引入退避逻辑，首选指数退避+随机抖动（jitter），配合 context 控制超时与取消，使用成熟库如 backoff/v4，避免硬编码 sleep、忽略错误分类及 goroutine 泄漏。
Go 里 time.Sleep 直接写死间隔会失败
硬编码重试间隔（比如每次 time.Sleep(1 * time.Second)）在真实服务调用中大概率触发雪崩或超时。下游抖动时，固定间隔既不能缓解压力，也无法适应恢复节奏。
实操建议：
- 必须引入退避逻辑，最常用的是指数退避（exponential backoff），但别手写乘法循环——容易溢出或忽略上限
- 优先用成熟封装，如
golang.org/x/time/rate不适用重试场景，应选github.com/cenkalti/backoff/v4或标准库生态兼容的轻量实现 - 初始间隔建议从
100 * time.Millisecond起步，避免首重试就压垮刚恢复的节点 - 一定要设最大重试次数和总超时时间，否则网络分区时 goroutine 泄漏
backoff.Retry 怎么配合自定义操作函数
第三方库的 backoff.Retry 接收一个无参函数，返回 error；它内部按策略调用，直到成功或放弃。关键在于：函数体不能包含阻塞式重试逻辑，否则会和退避机制冲突。
常见错误现象：context.DeadlineExceeded 频发，或重试次数远超预期
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 把实际请求逻辑（如 HTTP 调用、DB 查询）包进传入的
func() error，不要在里面调time.Sleep - 如果原函数带参数，用闭包捕获，例如：
func() error { return doRequest(ctx, url, payload) } - 注意错误分类：临时性错误（如
io.EOF、net.OpError）才重试；400 类 HTTP 错误或sql.ErrNoRows应直接返回，不进退避循环
自己实现指数退避时，rand.Int63n 加 jitter 是必须的
纯 2^n 退避在并发请求下会产生“重试风暴”：所有客户端在同一时刻发起重试，放大下游压力。jitter（随机扰动）是工业级实现的标配。
性能与兼容性影响：无 jitter 的退避在本地测试看似稳定，上线后高并发下失败率反而上升
实操建议：
- 每次计算间隔后，叠加 ±25% 的随机偏移：
delay = time.Duration(float64(base) * math.Pow(2, float64(attempt)))，再执行delay += time.Duration(rand.Int63n(int64(delay)/4)) - 用
rand.New(rand.NewSource(time.Now().UnixNano()))初始化独立 rand 实例，避免全局rand包被并发修改导致 panic - 最大间隔建议硬限制在
30 * time.Second以内，避免单次重试拖垮整体响应 SLA
Context 传递和取消必须贯穿整个重试链路
没透传 context.Context 是 Go 重试最隐蔽的坑：上游已取消，goroutine 却还在按计划 sleep 并重试，造成资源滞留和日志污染。
使用场景：HTTP handler、gRPC server 方法、定时任务子任务
实操建议：
- 所有重试函数签名必须接收
ctx context.Context，并在每次重试前用select { case 检查 - 不要用
time.After替代ctx.Done()，前者无法响应 cancel；sleep 时改用time.Sleep+ 手动检查ctx.Err()，或用timer := time.NewTimer+select组合 - 若底层操作本身支持 context（如
http.Client.Do），确保每次调用都传入当前重试上下文，而非原始 ctx —— 必要时用context.WithTimeout套一层单次尝试超时
真正难的不是算出第 n 次该睡多久，而是让每一次 sleep 都可中断、每一次错误都可分类、每一次重试都带着上下文呼吸感。漏掉其中任意一环，代码就只是看起来在重试。
