正确做法是在每次重试前主动刷新 token 并动态注入请求头：1. 封装幂等的异步刷新函数，缓存 pending promise；2. 重试循环中 await 刷新后再发请求；3. 解耦 token 注入，推荐请求前一刻通过拦截器或手动设置；4. 刷新失败时限制次数并跳转登录。
在 JavaScript 请求重试逻辑中，若 Token 有过期机制（如 JWT），直接重试旧请求会因鉴权失败而持续失败。正确做法是在每次重试前主动刷新 Token，并将新 Token 动态附加到请求头中。
1. 封装 Token 刷新逻辑
把获取新 Token 的过程抽象为一个 Promise 函数，支持异步刷新（例如调用 /auth/refresh 接口）：
- 确保该函数具备幂等性，避免并发刷新导致多次请求
- 可配合内存缓存（如用变量暂存 pending 的 refresh Promise）避免重复发起刷新请求
- 刷新失败时应抛出错误，让重试机制感知并终止或降级处理
2. 在重试前插入 Token 刷新步骤
不要在初始请求发出后才考虑 Token；而应在每次重试发起前，先执行刷新并等待完成：
- 使用 async/await 链式控制：重试循环中 await refreshAuthToken() 再发请求
- 若使用 axios，可在重试拦截器（如 axios-retry）的 retryDelay 或 retryCondition 钩子外，自定义 retry 前的 prepare 步骤
- 示例关键片段：const newToken = await refreshAuthToken(); config.headers.Authorization = `Bearer ${newToken}`;
3. 请求配置与 Token 动态注入解耦
避免把 Token 硬编码进请求配置对象。推荐在请求发送前一刻注入：
- 用 axios 的 request interceptor：每次请求前读取最新 Token（或触发刷新）
- 对重试场景，可临时禁用全局拦截器，在重试分支里手动 set header，确保刷新结果不被缓存干扰
- Token 存储建议用 secure httpOnly Cookie + 前端仅持短期访问 Token，刷新时由服务端自动续签更安全
4. 处理刷新失败与兜底策略
Token 刷新本身也可能失败（网络问题、refresh token 过期等），需有明确退出路径：
- 设定最大刷新尝试次数（如 1 次），避免无限循环
- 刷新失败后，清除本地凭证、跳转登录页，或提示用户重新登录
- 对非敏感接口，可允许无 Token 重试（如公开数据），但需业务层判断
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
