关键不是“要不要重试”，而是“怎么错开重试”：重试风暴源于大量失败请求在毫秒级窗口集中重发，需同时实现延迟拉长、时间打散、重试有界；带抖动的指数退避（如delay = basedelay × 2^attempt × (0.75 + math.random() × 0.5)）配合错误过滤（仅重试5xx、超时等）、队列串行化及全局策略管理，可有效化解风暴。
关键不是“要不要重试”，而是“怎么错开重试”。重试风暴的本质是大量失败请求在同一毫秒级窗口内集中重发，压垮本已脆弱的服务端。解决它需要三件事同时到位：延迟拉长、时间打散、重试有界。
用带抖动的指数退避控制重试节奏
固定延迟（比如每次等1秒）会让所有客户端像军训一样齐步走；指数退避让第1次等100ms、第2次等200ms、第3次等400ms……天然拉开时间差；再叠加±25%随机抖动，就能把原本可能集中在 1000ms 的重试，打散到 750–1250ms 这个区间。
- 计算公式建议：delay = baseDelay * Math.pow(2, attempt) * (0.75 + Math.random() * 0.5)
- 设上限防拖太久，例如最大延迟不超过 30 秒（Math.min(delay, 30000)）
- baseDelay 初始值推荐 100–500ms，避免首重试过急
用队列串行化并发重试任务
当多个请求几乎同时失败（比如页面加载时批量调用接口），若各自独立启动重试定时器，仍可能在抖动后“撞车”。引入轻量级重试队列，能强制错峰。
- 维护一个待重试任务数组（如 retryQueue = []）
- 每次只运行队首任务；它 resolve 或 reject 后，才 pop 下一个并启动其延迟
- 每个任务的延迟由自身 attempt 和策略独立计算，不共享计时器
- 避免用 setTimeout 堆积大量定时器，改用 Promise.delay().then() 链式推进
严格限制哪些错误值得重试
不是所有失败都该重试。对 400、404、422 等客户端错误重试，只会放大问题；对 5xx、网络中断、超时才应进入重试流程。
- 在 shouldRetry(error, response) 函数中明确拦截：response?.status >= 500 || !response || error.name === 'TypeError' || error.name === 'AbortError'
- 跳过 429（Too Many Requests），避免加重限流压力
- 对幂等性差的请求（如 POST 创建资源），默认禁用重试，或仅允许 1 次且必须带唯一 idempotency-key
全局统一策略 + 局部灵活覆盖
靠每个接口手写重试逻辑，极易遗漏或不一致。应建立中心化策略管理机制。
- 导出 setGlobalRetryPolicy() 设置默认策略（含 maxRetries、baseDelayMs、jitter、shouldRetry）
- 支持按 URL 正则覆盖策略，例如 overridePolicy(/^\/payment\//, { maxRetries: 0 }) 关闭支付类接口重试
- 提供 cancelAllPendingRetries() 应对用户主动离开页面等场景，清理未执行的重试计划
- 每次重试前记录日志：[retry] /api/order, attempt 2/3, delay 320ms，便于定位风暴源头
