直接断言backoff.ExponentialBackOff.Duration()返回值最可靠，需每次调用前b.Reset()；初始间隔100ms，首次返回50–150ms（含jitter），后续呈2ⁿ增长但受MaxInterval限制；禁用真实sleep，验证ctx.Done()响应性；并发下须为每次请求新建实例或显式重置。
怎么用单元测试验证 backoff/v4 的退避间隔是否符合预期
直接断言 backoff.ExponentialBackOff.Duration() 返回值是最可靠的方式。它的每次调用只依赖当前 attempt 计数和已设参数，不依赖时间或外部状态，适合纯函数式验证。
关键点是：必须在每次 b.Duration() 前手动调用 b.Reset()，否则 attempt 会累积，导致第二次测试拿到的不是第 1 次的间隔，而是第 n+1 次的值。
- 初始间隔设为
100 * time.Millisecond，b.Duration()第一次应返回约 100ms（带 jitter 后在 50–150ms 区间） - 连续调用三次
b.Duration()（中间不Reset），应看到大致呈 2ⁿ 增长趋势，但每次有随机偏移 - 设置
b.MaxInterval = 30 * time.Second后，多次调用最终会稳定在该值附近，不再指数增长 - 别测
backoff.RetryNotify的总耗时——它受业务函数执行时间干扰太大，无法隔离验证退避逻辑本身
如何 mock 网络错误触发重试并检查 notify 回调行为
重试流程是否真正按退避节奏执行，不能只看间隔，还要看它是否在正确时机、以正确参数调用了你的 notify 函数。这时需要控制业务函数的失败行为，并捕获回调调用。
推荐做法是：用一个计数器变量 + 闭包模拟失败操作，配合 time.Now() 打点记录每次 notify 调用的时间戳，再比对相邻两次的时间差是否落在预期 jitter 区间内。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 让操作函数前
n-1次返回net.OpError，第n次返回nil，可精确控制重试次数 -
notify函数里把t存入切片，最后检查切片长度是否等于重试次数（含最后一次成功前的失败） - 注意：
t是本次重试“开始时间”，不是 sleep 结束时间，所以两次t的差值 ≈ 上次的b.Duration()，而非本次 - 别用
time.Sleep(1 * time.Nanosecond)去“等回调”——测试会不稳定；用同步 channel 或原子计数器更可控
为什么不能用真实 time.Sleep 写集成测试验证重试耗时
因为真实 sleep 会让测试变慢、不可靠，且掩盖退避逻辑本身的缺陷。比如你误把 MaxElapsedTime 当成单次最大等待时间，测试跑出来“好像没超时”，其实只是凑巧没触发边界条件。
真正要测的是：退避策略是否在 context 取消后立刻停止。这必须用 mock 时间源或替换底层 timer —— 但 backoff/v4 不支持注入 clock，所以更务实的做法是验证其对 ctx.Done() 的响应性。
- 构造一个已 cancel 的
ctx，传给backoff.WithContext(b, ctx)，再喂给RetryNotify - 观察是否立即返回错误（如
context.Canceled），而不是先 sleep 再检查 - 若看到日志里出现 “retry #1 failed at …: context canceled”，说明它在第一次
NextBackOff()就退出了，这是正确行为 - 任何依赖真实时间流逝的测试，都应在 CI 中被标记为 flaky 并禁用
测试中容易忽略的并发安全陷阱
多个 goroutine 共享同一个 backoff.BackOff 实例时，attempt 计数器会互相覆盖。这个问题在线上可能几个月不暴露，但在压测或并发单元测试里一跑就崩。
最简单的复现方式：启动 2 个 goroutine，各自调用同一 b 的 Duration() 10 次，打印每次结果。你会发现两组序列混在一起，比如 A 拿到第 1 次间隔，B 紧接着也拿到第 1 次间隔，而不是各自从 1 开始。
- 单元测试里若用 for 循环反复调
RetryNotify，必须确保每次循环都 new 一个backoff.ExponentialBackOff，或显式b.Reset() - 别在 test helper 函数外定义全局
b := backoff.NewExponentialBackOff()—— 它会被所有子测试共享 - 如果封装了重试客户端，它的
Do()方法内部必须为每次请求新建退避实例，或接收 caller 传入的已 reset 实例 - mock 的业务函数里加
runtime.Gosched()可放大竞态，帮助发现这类问题
测试重试机制真正的难点不在“能不能跑通”，而在于确认它不会在并发、取消、错误类型混合场景下悄悄失效——那些 bug 往往只在高负载或下游抖动时才浮出水面。
