遇到401响应时需先刷新Token再重试请求，核心是拦截失败、串行化重试并避免并发刷新；通过全局refreshPromise缓存刷新任务，更新Token后重放等待队列中的请求，并处理刷新失败等边界情况。
在 Fetch API 中遇到 401 响应时，不能简单重试请求，而需先刷新 Token，再用新 Token 重发原请求。核心在于拦截失败、触发刷新、串行化重试，避免多个并发请求同时触发多次刷新。
捕获 401 并暂停原始请求
不直接在每个 fetch 调用里写判断，而是封装统一的请求函数。当响应状态为 401 时，不立即 reject，而是暂存该请求（含 method、url、body、headers），等待 Token 刷新完成后再重放。
- 用 Promise 构造器包装 fetch，便于控制 resolve/reject 时机
- 检查 response.status === 401，且尚未处于“刷新中”状态
- 将当前请求推入等待队列，避免重复发起刷新请求
确保 Token 刷新只执行一次
多个并行请求同时收到 401 时，必须防止多个刷新请求并发发出。可用一个全局 Promise 缓存刷新任务：
- 声明 let refreshPromise = null
- 首次遇到 401：调用 refreshToken() 并赋值 refreshPromise = refreshToken()
- 后续 401：直接 await refreshPromise，复用同一 Promise
- 刷新成功后清空 refreshPromise，为下次做准备
刷新后重试原请求（带新 Token）
Token 刷新成功后，从存储（如 localStorage 或内存变量）更新 accessToken，并遍历等待队列，为每个请求的 headers 重新注入 Authorization 字段，再逐个 fetch：
立即学习“Java免费学习笔记（深入）”；
- 复制原 RequestInit 对象，避免修改原始配置
- 设置 headers.Authorization = `Bearer ${newToken}`
- 用新的配置重新调用 fetch，返回其 Promise 结果
- 对重试结果仍做状态检查，防止新 Token 也失效（如 401 再次出现则跳转登录）
处理边界与降级逻辑
自动刷新不是万能的。需考虑刷新失败、Token 持久化丢失、用户已登出等场景：
- refreshToken() 返回 401/403 或网络失败 → 清空本地凭证，跳转登录页
- 等待队列中的请求超时（可选加 timeout 控制），避免永久挂起
- 敏感操作（如支付、删除）不自动重试，401 直接提示用户重新登录
- 刷新期间禁用相关按钮或显示 loading，避免用户重复提交
