指数退避

指数退避指失败后按指数增长的间隔进行重试的策略，例如等待 1 秒、2 秒、4 秒、8 秒。配合随机抖动可以避免大量客户端在同一时刻集体重试。它适用于限流（429）与服务端临时故障（5xx）这类会自行恢复的错误，不适用于参数错误、认证失败与额度耗尽。

为什么不能固定间隔猛重试

触发限流之后继续高频重试，会让计数窗口持续被填满，限制反而持续更久。服务端过载时也一样：所有客户端同时重试，只会让恢复更慢。

指数退避的思路是「越失败越有耐心」：1 秒、2 秒、4 秒、8 秒，并设一个最大等待上限与最大重试次数。

再加一点随机抖动——在等待时间上叠加一个小的随机量，避免成千上万个客户端在同一秒集体重试。

哪些错误该重试，哪些不该

错误	该不该重试
429 速率超限	该，退避后通常恢复
5xx 上游故障	该，退避后重试
连接超时	该，但要考虑重复请求的风险
429 额度耗尽	不该，重试多少次都不会成功
401 认证失败	不该，先查密钥
400 参数错误	不该，先改请求

盲目对所有错误重试是最常见的实现错误，它会把「充值就能解决」的问题变成一场徒劳的重试风暴，还可能烧掉大量额度。

优先用服务端给的建议值

很多接口在限流时会通过响应头给出建议等待秒数。有这个值就用它，比自己算的退避时间更准确。相关响应头见 HTTP Header。

本站哪里会遇到

三篇官方 API 教程都会在错误处理一节提到它；超时与重试要配合使用，避免超时后的重试造成重复计费。