js请求重试需支持异步条件判断、带取消与竞态防护、指数退避+抖动+队列化错峰、ui可感知与业务降级，确保真实场景下的可靠性与用户体验。
掌握 JS 请求重试机制的高级进阶技巧，关键不是堆砌功能，而是让重试行为更贴合真实场景：可判断、可中断、可错峰、可降级。下面几个方向是生产环境真正用得上的核心能力。
支持异步条件判断的重试决策
很多重试失败，是因为“该不该重试”靠静态错误码拍脑袋决定。比如 token 过期后首次请求失败，需先刷新 token 再重试；又比如轮询某个任务状态，必须等返回 status: "processing" 才继续，否则直接终止。
- 把
shouldRetry设计成返回Promise<boolean></boolean>的函数，内部可 await token 刷新、权限校验或状态查询 - 每次失败后先执行该函数，为
false或抛错就立刻终止，不消耗重试次数 - 避免在重试链中重复发起副作用请求（如多次调用
refreshToken()），建议加缓存或状态锁
带取消与竞态防护的重试任务
用户切页、连点按钮、快速切换筛选条件时，旧重试还在跑，新请求已发出——若不处理，轻则 UI 显示错乱，重则数据覆盖、重复提交。
- 每次重试都新建
AbortController，并将signal传给fetch，确保网络层真正中止 - 用递增的
attemptId标记每次重试，响应返回时比对是否仍是最新一次，过期则丢弃 - 暴露
cancel()方法，调用时清除定时器、中止信号，并拒绝当前 pending 的 Promise
指数退避 + 抖动 + 队列化错峰
单纯延时重试容易引发“重试风暴”：上百台手机在 1s 后同时重发请求，压垮本就吃紧的服务端。
- 延迟按
baseDelay × 2^attempt增长（如 500ms → 1s → 2s），并叠加Math.random() * 当前延迟抖动 - 多个请求失败时，不各自启动定时器，而是进入共享队列；每次只运行队首任务，完成后再调度下一个
- 队列内每个任务独立计算延迟，互不干扰，既防并发冲击，又保重试节奏可控
UI 可感知、业务可降级的重试体验
重试不是后台黑盒逻辑，用户需要知道“发生了什么”和“我能做什么”。尤其在移动端，等待超过 2 秒就必须给反馈。
- 首次失败静默重试；第二次失败显示 Toast：“网络不稳定，正在重试…”；第三次失败提供明确操作入口（如“手动重试”按钮）
- 对非关键请求（头像加载、埋点上报）失败直接忽略，不阻塞主流程，也不触发重试
- 关键请求失败且重试耗尽后，展示离线缓存内容、骨架屏占位或简化版兜底数据，保持界面可用性
