JavaScript请求重试应采用指数退避加截断抖动策略：第n次失败后等待Math.random()*2ⁿ⁻¹×1000ms，上限约30秒，避免同步重试冲击下游服务。
在 JavaScript 请求重试中结合指数退避策略，核心是让每次重试的等待时间随失败次数呈指数增长（如 1s → 2s → 4s → 8s），避免密集重试冲击服务端或触发雪崩。它不是简单固定延时，而是有节奏、有上限、带随机性的“智能暂停”。
为什么用指数退避而不是固定延迟
固定延迟（比如每次都等 1 秒）在连续失败时容易形成请求洪峰，尤其多用户/多实例同时重试，会加剧后端压力；而指数退避天然拉开重试时间点，显著降低并发重试概率。实际数据显示，合理使用该策略可将重试引发的二次失败率降低 40% 以上。
基础实现：按尝试次数计算等待时间
第 n 次重试前的等待毫秒数通常为：delay = Math.min(baseDelay * Math.pow(2, attempt), maxDelay)
其中：
• baseDelay 是初始延迟（常用 500ms 或 1000ms）
• attempt 是当前重试次数（从 0 开始）
• maxDelay 是最大等待上限（防止无限拉长，如 30000ms）
必须加抖动：防同步重试风暴
纯指数退避仍可能因多个客户端启动时间接近而“步调一致”。加入随机抖动（jitter）可打破这种同步性：
• 在计算出的基础延迟上，叠加一个 0 ~ delay 范围内的随机值
• 示例代码片段：
const baseDelay = Math.pow(2, attempt) * 1000;
const jitter = Math.random() * baseDelay;
await new Promise(r => setTimeout(r, baseDelay + jitter));
哪些错误才值得指数重试
盲目重试会浪费资源甚至引发副作用（如重复下单）。应只对以下类型错误启用：
• 网络层异常：TypeError: Failed to fetch、AbortError（超时）
• 服务端临时错误：HTTP 状态码 5xx（500、502、503、504）
• 明确排除：4xx 错误中除 408（Request Timeout）外多数不重试，如 400、401、403、404、422 等属于客户端问题或业务拒绝，重试无意义
