先决定哪些错误可以重试

错误类型默认策略
连接超时、临时网络错误有限重试
429 或服务端限流遵循 Retry-After；退避并降速
部分 5xx根据接口幂等性有限重试
400 参数错误、401/407 认证错误、403 权限错误停止重试并修正配置

如果一次操作可能产生订单、扣费或状态变更，应先确认接口是否支持幂等键，不能把读取接口的重试逻辑直接复制给写入接口。

指数退避与随机抖动

指数退避让后续尝试逐步拉开，随机抖动避免大量客户端在同一时刻再次请求。AWS 官方重试文档采用指数退避加 full jitter 的思路，并设置最大等待上限。

delay = random(0, min(cap, base * 2 ** attempt))

公式只是起点。最大尝试次数、总任务时限、服务端 Retry-After 和业务优先级都应一起决定。

每一层只重试一次

浏览器、SDK、业务服务、网关和任务队列如果都独立重试，同一次故障会被成倍放大。选择最了解接口语义的一层实施重试，其余层应传递清晰错误或使用严格预算。

为单次调用设置连接和读取超时，为整个业务任务设置截止时间。剩余时间不足时不要再开启一次注定无法完成的重试。

观测与熔断

至少记录总请求、首次成功、重试成功、最终失败、429、5xx、连接超时和每次退避时间。指标按接口和错误类别聚合，不记录代理密钥、完整请求参数或客户数据。

当错误率持续超过阈值时，应停止放大流量，进入降级或熔断状态，并由健康检查决定何时恢复少量探测。

上线验收

  1. 用模拟 429、5xx、超时和认证失败验证分类。
  2. 确认认证失败不会重试。
  3. 确认写入操作使用幂等键或明确禁止自动重试。
  4. 并发压测时观察是否出现同步重试尖峰。
  5. 验证达到最大次数或总截止时间后能及时停止。

常见问题

所有 5xx 都应该重试吗？

不是。要结合接口是否幂等、剩余时间、错误含义和服务端指示；重复写入可能产生副作用。

为什么退避还要加入随机抖动？

如果所有客户端按相同间隔重试，会在同一时刻形成新的流量尖峰；随机抖动用于分散重试时间。

429 应该怎么处理？

优先遵循服务端 Retry-After 或官方限流说明，同时降低并发，并在有限次数后停止。

继续阅读

主要参考资料

资料最后复核：2026-09-05。外部文档可能更新，操作前请核对来源页面当前版本。