无感token刷新核心是fetch响应拦截+双token机制+请求暂存重放：401时用refresh_token换新access_token，通过isrefreshing标志防并发，暂存请求参数并重发，失败则清凭证跳登录。

用 fetch 实现无感 Token 刷新，核心是靠响应拦截逻辑 + 双 Token 机制 + 请求暂存重放，不依赖 Axios 等库，完全可控且轻量。

双 Token 机制是基础

必须后端配合提供两个 Token：

• access_token：短期有效（如 30 分钟），每次请求放在 Authorization: Bearer xxx 头里；
• refresh_token：长期有效（如 7 天），只用于换取新 access_token，建议存在 HttpOnly Cookie 中（更安全），或加密后存 localStorage。

前端不解析、不校验 refresh_token，只在需要时原样提交给后端刷新接口（如 POST /auth/refresh）。

fetch 封装：统一处理 401 和刷新流程

不能每个 fetch 都手动判断 401，要封装一个自定义请求函数，内建拦截与恢复能力：

• 用 Promise 链和闭包变量（如 isRefreshing）控制刷新状态，避免并发触发多次刷新；
• 遇到 401 时，若未在刷新中，就调用刷新接口；若已在刷新中，把当前请求“挂起”，加入待重试队列；
• 刷新成功后，更新本地 access_token（比如写入 sessionStorage），再批量重放队列里的请求；
• 刷新失败（如 refresh_token 也过期），清空凭证并跳转登录页。

关键细节：如何挂起并重放 fetch 请求

fetch 本身不可取消或重放，所以得把原始请求参数（url、method、headers、body）缓存下来，等新 token 到位后，用新 header 重新构造一次 fetch：

• 不要直接 await fetch(...) 后再处理，而是封装成返回 Promise<response></response> 的函数；
• 队列中存的是“请求描述对象”+“resolve/reject 回调”，不是 Promise 实例本身；
• 重放时，需深拷贝 body（如 JSON 字符串需重新 parse 后 stringfy），避免因流已读导致报错；
• 对 GET 或无 body 请求较简单；对 POST/PUT 含 FormData 或 ArrayBuffer 的，建议统一转为 JSON 提交，降低重放复杂度。

不推荐“提前预刷新”策略

有些方案会在 access_token 剩余 60 秒时主动刷新——看似平滑，实则风险高：

• 本地时间不准会导致误判（用户调快系统时间，token 显示“还剩 2 小时”，其实已过期）；
• 频繁无效刷新增加后端压力；
• 无法覆盖网络延迟、服务响应慢等真实过期场景。

真正可靠的时机只有一个：后端明确返回 401 Unauthorized 并带标准语义（比如 {"code": 401, "message": "access token expired"}）。