应使用 time.AfterFunc 模拟重试延迟而非 time.Sleep，因其不阻塞 goroutine、更贴近真实异步调度；需预热计时器、避免 Gosched、注意 math.Exp 溢出及整数截断。
用 time.AfterFunc 模拟重试延迟，别用 time.Sleep
测试退避算法时，直接 time.Sleep 会阻塞 goroutine，导致并发逻辑失真、超时难控、难以验证时间点精度。真实重试场景中，每个重试是异步触发的，time.AfterFunc 更贴近调度本质。
- 用
time.AfterFunc启动回调，记录触发时间戳，再比对与预期退避时间的误差（建议容忍 ±5ms） - 测试前调用
time.Sleep(10 * time.Millisecond)预热系统计时器，避免首次调用time.Now()出现抖动 - 不要在测试中依赖
runtime.Gosched()“让出”时间片——它不保证调度时机，反而掩盖时序问题
验证指数退避时，注意 math.Exp 溢出和整数截断
Go 标准库没有内置指数退避函数，手写时容易忽略浮点计算边界。比如 base * math.Exp(float64(attempt) * math.Log(2)) 在 attempt > 70 时会返回 +Inf，后续转 time.Duration panic。
- 用
int64(base) 替代浮点指数运算（仅限 base 是 2 的幂且无 jitter 场景） - 若需 jitter，先算出理论值，再用
rand.Int63n(maxJitter)加偏移，最后用min(duration, maxDuration)截断 - 测试必须覆盖
attempt = 0, 1, 5, 15, 30—— 尤其 15+ 容易暴露溢出或整型溢出（int64最大值约 9e18 纳秒 ≈ 285 年）
测试 jitter 逻辑，得固定 rand.New 种子并检查分布
jitter 不是“随便加个随机数”，而是要在 [0, retryDuration) 区间均匀采样。不固定种子会导致测试非确定性；不校验分布则可能把 jitter 写成常量或全零。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 构造测试用的
*rand.Rand：r := rand.New(rand.NewSource(123))，所有 jitter 调用都走它 - 运行 1000 次同参数重试，收集所有 jitter 值，确认最小值 ≥ 0、最大值
- 避免用
rand.Intn(0)这类错误调用——它 panic，但只在运行时暴露，单元测试里要显式测边界
用 testify/mock 或接口隔离外部依赖，否则重试测试不可靠
如果重试逻辑耦合了 HTTP 请求、数据库查询等，测试就变成集成测试，失败原因可能是网络抖动、DB 延迟，而非退避算法本身。
立即学习“go语言免费学习笔记（深入）”；
- 把可重试操作抽象为函数类型：
type Doer func() error，测试时传入闭包模拟失败/成功 - 若已有结构体方法，定义 interface 并让其实现，测试时用 struct{} 实现 mock 行为
- 禁止在测试中启动真实 http.Server 或连接本地 Redis——它们引入非可控延迟，让“第 3 次重试是否在 400ms±10ms 内触发”无法断言
退避时间测试真正的难点不在算法实现，而在如何剥离环境噪声、锁定随机性、并精确到毫秒级观测异步触发点。漏掉任意一环，测出来的“正确”都是偶然。
