必须每次重试前重新生成鉴权签名，因时间戳、nonce、token等动态参数会过期或失效；应封装generateAuthHeader函数并在重试循环内调用，同时协同刷新token。
在 JavaScript 请求重试中更新鉴权签名，核心是**每次重试前重新生成签名**，而不是复用首次请求的过期签名。这是因为签名通常依赖时间戳、随机数（nonce）、token 有效期等动态参数，重试时这些值很可能已失效。
为什么重试时必须更新签名
常见鉴权方式（如 HmacSHA256 + 时间戳 + nonce + token）要求：
- 时间戳（timestamp）需与服务端时间偏差在允许窗口内（如 ±300 秒），重试延迟后原时间戳可能超时；
- 随机数（nonce）通常要求一次一密，重复使用会被服务端拒绝；
- Token 可能已过期或被刷新（如 OAuth2 的 access_token 刷新流程）；
- 签名原文（如请求路径、body、header 拼接）若含动态字段，也需同步更新。
推荐实现方式：把签名逻辑封装成函数
不要在请求发起前“一次性计算签名并固定使用”，而是将签名生成逻辑抽象为独立函数，在每次重试前调用：
HMAC ${token.accessKey}:${signature}
注意 Token 刷新与签名协同
如果服务端返回 401 表示签名无效或 token 过期，重试前应主动刷新凭证：
- 调用 refreshAccessToken() 获取新 token（可能涉及 refreshToken）；
- 确保 generateAuthHeader 内部调用的 getValidAccessToken() 返回的是最新有效 token；
- 避免并发重试导致多次刷新，可用 Promise 缓存刷新过程（如用一个 pendingRefresh Promise 锁住）。
常见踩坑点
✘ 错误做法：在 retry 循环外生成签名，所有重试共用同一套 header；
✘ 忘记更新 timestamp/nonce —— 即使 token 没过期，旧时间戳也可能被拒；
✘ 签名依赖了未更新的 body 或 query 参数 —— 比如重试时 body 被序列化两次，或 URL 查询参数没同步更新；
✘ 在 fetch 中直接写死 headers 对象字面量，没在每次循环中重建。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
