统一退避函数若未加随机抖动，会导致所有客户端同步重试，瞬间涌向服务端引发雪崩；backoff.withjitter通过在[min, max]区间均匀随机采样实现错峰，避免惊群效应。
为什么统一退避函数反而加剧雪崩
统一退避函数如果没加随机抖动，会让所有客户端在相同时间点发起重试请求。比如 time.Sleep(2^retry * time.Second) 在第 3 次重试时，1000 个实例全卡在 8 * time.Second 后同一毫秒发包——这不是“重试太勤”，而是时间完全同步。服务端瞬间收到千并发，连接数、goroutine、CPU 齐齐翻倍，context.DeadlineExceeded 错误陡增。
backoff.WithJitter 是怎么打散重试时间的
它不是简单乘个 0.5~1.5 系数，而是把每次退避时间映射到 [min, max] 区间做均匀随机采样。例如你设 bo.MaxInterval = 10 * time.Second，第 3 次退避实际等待可能是 3.2 秒、7.9 秒、1.1 秒……真正错峰。
-
backoff.NewExponentialBackOff()默认MaxInterval是 128 秒，必须手动缩到 10~30 秒内 -
backoff.WithJitter()必须在初始化后调用，不能漏 - 别自己 new
rand.Rand全局变量并发调用——会 panic；backoff/v4内部已处理线程安全
gRPC 和 HTTP 重试策略不能混用
gRPC 客户端用 grpc_retry.WithBackoff()，HTTP 客户端用 backoff.Retry()，两者底层超时模型不同：gRPC 的 PerRetryTimeout 控制单次调用，而 backoff.Retry 外层套 context.WithTimeout 控制总耗时。混用会导致超时被稀释或失效。
- gRPC 重试必须配
grpc_retry.WithPerRetryTimeout，否则单次失败可能拖满整个退避周期 - HTTP 调用别在每次重试里新建 context，要在最外层套
context.WithTimeout - 错误判断逻辑要分开：gRPC 看
status.Code(err)，HTTP 看resp.StatusCode或err类型
重试前必须检查是否幂等
哪怕退避再优雅，对非幂等操作（如 CreateOrder）直接重试，就是制造重复数据。RPC 方法本身不承诺幂等性，得靠外部机制兜底。
- 客户端生成唯一
idempotency_key，服务端用 Redis 或 DB 唯一索引判重 - 重试前先查状态：比如调
GetOrder(id)确认是否已创建成功 - 服务端返回
codes.AlreadyExists时，应终止重试并透传结果 - 别依赖“重试次数少就没事”——1 次重试也足以造成订单重复
关键点不在退避公式多精巧，而在抖动是否真随机、超时是否真有效、错误是否真可重试。漏掉任意一环，雪崩风险就藏在下次网络抖动里。
