登录态自动刷新队列的核心是共享 pending 刷新 promise 并维护重试队列：首次 token 过期时发起 refreshtoken 请求并缓存其 promise，后续请求复用该 promise；同时将 401 请求入队，刷新成功后统一重发，失败则批量拒绝，并注意刷新接口免鉴权、内存+持久化双层 token 存储及防重复触发。
登录态自动刷新队列的核心是：当 token 过期时，后续所有依赖有效 token 的请求不能各自发起刷新，而应共享同一个刷新请求，并让它们排队等待新 token 返回后再重试。
用一个 pending 刷新 Promise 全局共享
首次发现 token 过期时，触发 refreshToken 接口，并把返回的 Promise 缓存起来；后续请求检测到刷新正在进行，就直接复用这个 Promise，而不是重复调用刷新接口。
- 定义一个变量（如 refreshingPromise），初始为 null
- 每次请求前检查 token 是否即将过期（比如剩余 60 秒内）
- 若需刷新且 refreshingPromise 为 null，就调用 refreshToken() 并赋值给它
- 若 refreshingPromise 已存在，直接 await 它，拿到新 token 后继续原请求
请求拦截器中统一处理刷新逻辑
在 axios 或自定义 fetch 封装里做拦截：请求发出前检查 token，响应 401 时触发刷新流程，再重发原请求。
- 响应拦截器捕获 401 错误，不立即 reject，而是进入刷新流程
- 刷新成功后，更新本地 token（localStorage / memory）、更新请求头中的 Authorization
- 用原始 config 重新发起一次请求（注意避免无限循环，可加标记字段如 _retry: true）
- 刷新失败则清除登录态，跳转登录页
防重复、防丢失：用队列 + 状态标记
仅靠 Promise 共享还不够，极端情况下（如快速连续多个 401）可能漏掉部分请求。可维护一个待重试队列，确保每个失败请求都被记录和执行。
- 声明一个数组 retryQueue = []，存放 { config, resolve, reject } 对象
- 遇到 401 时，把当前请求推入队列，不立刻执行，等刷新完成统一重放
- 刷新成功后，遍历队列，逐个用新 token 重发；刷新失败则批量 reject 所有队列请求
- 队列清空后重置状态，避免残留
注意边界与细节
实际落地时容易忽略几个关键点：
- 刷新接口本身不能走带 token 的鉴权，否则会死锁（刷新也要 token？那 token 又从哪来？）
- token 存储建议分两层：内存中存当前 token（便于快速判断是否过期），持久化存 refresh_token（用于换取新 access_token）
- 避免“刷新中又触发刷新”——所有刷新入口都要先判断 refreshingPromise 是否存在
- 前端时间不可信，token 过期判断尽量结合服务端返回的 expires_in 或 exp 字段 + 本地时间校准
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
