go中带权重重试需用backoff.retry配合自定义backoff实例，按错误类型动态调整退避策略；每个请求必须独立新建backoff实例，避免状态污染；需协同熔断器与上下文超时实现精准削峰。
用 backoff.Retry 配合自定义重试策略实现权重控制
Go 里没有原生“带权重的重试”概念，所谓权重，本质是让不同错误类型或不同服务端响应走不同的退避策略（比如 503 多试几次、400 直接失败），或者让某些错误触发更长的等待间隔。直接套用 backoff.Retry + 自定义 backoff.BackOff 是最可控的做法。
常见错误是把“权重”理解成概率采样——重试不是随机跳过，而是根据错误特征动态调整是否重试、等多久再试。
- 用
backoff.WithMaxRetries控制总次数，但真正决定“该不该试第 N 次”的逻辑要写在backoff.Retry的回调函数里 - 把错误分类提取成可比较的标签，比如封装一个
RetryableError类型，带.Code和.Weight字段 - 不要在重试函数里做状态突变（如修改全局计数器），否则并发下行为不可预测
HTTP 错误码映射到不同重试间隔：别硬编码 time.Sleep
流量削峰场景下，你希望对临时性错误（如 503 Service Unavailable）拉长退避，而对客户端错误（如 400 Bad Request）立刻放弃。这时候手写 time.Sleep 不仅难维护，还会破坏重试库的指数退避节奏。
正确做法是组合 backoff.ExponentialBackOff 和错误判定逻辑：
立即学习“go语言免费学习笔记（深入）”；
- 在重试回调中用
errors.As判断是否为*url.Error，再检查.Err是否含"timeout"或"connection refused" - 对
5xx错误，调用bo.Reset()并设置bo.MaxInterval = 5 * time.Second；对4xx直接返回非重试错误 - 注意
backoff.ExponentialBackOff的InitialInterval默认是 10ms，生产环境建议设为100ms起步，避免瞬时重试压垮下游
并发请求下的重试竞争：每个请求必须有独立的 backoff.BackOff 实例
多个 goroutine 共享同一个 backoff.BackOff 实例会导致退避状态错乱——比如 A 请求刚重试完重置了计数器，B 请求紧接着拿到的是已被重置的状态，实际退避间隔远小于预期。
这是线上最容易被忽略的坑，现象是“重试没生效”或“重试间隔忽长忽短”。根本原因是 backoff.BackOff 是有状态的对象，不是纯配置。
- 每次发起请求前，都用
backoff.NewExponentialBackOff()新建实例，不要复用 - 如果需要统一管理最大重试次数或超时，把控制逻辑提到外层，比如用
context.WithTimeout包裹整个重试过程 - 别为了“节省对象分配”把
BackOff做成池子——它的内存开销极小，状态污染代价远高于 GC 成本
流量削峰时的熔断协同：重试不是万能的，得配合 circuitbreaker
单纯加权重重试，在突发流量下可能把失败请求越积越多，最终拖垮调用方。真正的削峰需要和熔断联动：当错误率超过阈值，直接跳过重试，快速失败。
推荐用 sony/gobreaker，它提供 cb.Execute 接口，天然适合嵌套重试逻辑：
- 把重试逻辑包在
cb.Execute的执行函数里，熔断器自动统计成功/失败 - 设置
gobreaker.Settings{ReadyToTrip: func(counts gobreaker.Counts) bool { return counts.TotalFailures > 50 && counts.TotalRequests > 100 }} - 注意熔断器的
OnStateChange回调里别做耗时操作，否则会卡住整个重试流程
重试的复杂点从来不在“怎么多试几次”，而在于“什么时候不该试”。权重、熔断、上下文超时三者得咬合着设计，漏掉任意一环，削峰就变成添堵。
