平滑指数退避需抖动+响应优先+令牌桶协同：用随机因子避免重试共振，优先采用Retry-After头，结合令牌桶限频；调度器须支持cancel/pause，时间计量改用performance.now()并节流localStorage同步。
平滑指数退避不是简单地用 Math.pow(2, n) 硬切时间片，而是要在重试间隔中引入随机扰动、动态响应服务反馈（如 Retry-After）、并和限频机制耦合——否则容易在下游恢复瞬间引发请求洪峰。
为什么直接 Math.pow(2, n) 会出问题
纯指数增长的延迟曲线太陡峭且确定，实际场景中会出现两个典型问题：
- 多个客户端在同一失败点重试时，会在第 3 次重试后几乎同时发起请求，形成“重试共振”，反而压垮刚恢复的服务
- 当后端返回
503 Service Unavailable并带Retry-After: 12时，若仍坚持按baseDelay * 2^attempt算出 8000ms，就浪费了服务端给出的精确调度信号 - 没有对单位时间总请求数做约束，比如每分钟最多允许 5 次重试，否则即使单次退避拉长，高频触发任务仍可能突破 QPS 阈值
实现平滑退避的关键三步：抖动 + 响应优先 + 令牌桶协同
真正的平滑不靠“更精细的 baseDelay”，而靠三个动作的叠加：
-
抖动（Jitter）：每次计算延迟后乘以
0.5 ~ 1.0的随机因子，例如delay = baseDelay * Math.pow(2, attempt) * Math.random() * 0.5 + 0.5，避免集群重试同步化 -
响应优先（Response-aware）：在
catch块中解析err.response?.headers.get('Retry-After')，若存在则直接用该值（单位秒），并跳过指数计算；对429响应也同理处理 -
令牌桶协同：维护一个
Map<string number></string>记录每个url最近 60 秒内所有重试发起时间戳，每次重试前过滤过期项，若剩余数量 ≥ 阈值（如 5），则强制将本次 delay 设为60000 - (Date.now() - earliestTimestamp)
Promise 调度器必须暴露 cancel 和 pause 接口
高可用 ≠ 无限重试。生产环境里，一个卡住的异步任务如果不能被外部干预，就会拖垮整个调度队列：
-
requestWithRetry函数应返回一个带cancel()方法的对象，内部用AbortController控制 fetch，并在cancel()中调用abort()清理未决 Promise - 调度器实例需支持
pause(urlPattern: RegExp)，匹配到的 URL 后续重试全部进入等待队列，直到resume()被调用——这对灰度发布或紧急熔断至关重要 - 不要把重试逻辑全塞进单个
async函数里；应拆成scheduleAttempt()（决定是否重试+算 delay）、executeWithTimeout()（封装 fetch + AbortSignal）、recordOutcome()（更新令牌桶）三个可单独测试的单元
最容易被忽略的边界：时钟漂移与跨 Tab 同步
浏览器环境里，用户切换标签页、系统休眠、NTP 校时都可能导致 Date.now() 跳变。如果你用它计算“60 秒窗口”，就可能漏判或误判令牌桶状态。解决方案只有两个：
- 改用
performance.now()做相对时间计量，配合启动时记录的startTime = performance.now()，所有“60 秒”逻辑转为if (performance.now() - startTime > 60000) - 若需跨 Tab 共享令牌桶状态（比如防止用户开 5 个页面同时刷接口），必须用
localStorage+storage事件同步，但要注意写入频率——每毫秒一次 update 会卡死主线程，应节流到至少 100ms 一次
