应封装 getAuthHeader() 函数统一生成鉴权头，动态处理前缀、多段结构、时间戳与签名，避免重复拼接；密钥须安全注入，JWT 需解析 payload 判断过期。
JavaScript 中处理复杂鉴权 Token（比如带前缀、多段结构、需动态拼接或含时间戳/签名的 Token）的关键，是把 Token 的生成、刷新、注入和失效判断从请求逻辑中解耦出来，避免每个 fetch 或 axios 调用都手动拼接。
统一管理 Token 构造逻辑
复杂 Token 常见形式如：Bearer eyJhbGciOiJIUzI1Ni...xT2VfQ、Custom v1:uid:timestamp:signature、或需拼接 client_id + timestamp + HMAC-SHA256 签名。不要在每次请求时重复写构造代码。
- 封装一个
getAuthHeader()函数，内部根据当前登录态、过期时间、必要参数（如 nonce、时间戳）动态生成完整 Header 值 - 若 Token 含签名，确保密钥不硬编码，通过安全方式注入（如环境变量 + 构建时替换，或后端下发临时密钥）
- 对 JWT 类 Token，可解析 payload 判断是否即将过期（例如剩余
在请求层自动注入与拦截
用请求库的拦截机制（如 axios 的 interceptors.request，或全局 fetch 包装器）统一加 Header，而非每个 API 调用都手动设 Authorization。
- axios 示例：在 request 拦截器中调用
getAuthHeader()，若返回 null（如未登录或 Token 无效），可跳过请求或重定向到登录页 - 原生 fetch 封装示例：定义
authFetch(url, options = {})，内部合并{ headers: { ...options.headers, Authorization: getAuthHeader() } } - 注意：避免在拦截器里同步读取异步数据（如 localStorage 里的加密 Token），应预先解密并缓存，或改用 async 拦截（如 axios@1.7+ 支持 async request interceptor）
应对 Token 刷新与并发请求冲突
当 Token 过期后首次请求 401，触发刷新流程时，多个并发请求可能同时收到 401 并各自发起刷新，造成重复请求或状态错乱。
立即学习“Java免费学习笔记（深入）”；
- 用 Promise 缓存刷新动作：首次 401 触发刷新时，保存返回的 Promise；后续同阶段的 401 请求 await 同一个 Promise，共享新 Token
- 刷新成功后，更新本地存储（如 sessionStorage）和内存缓存，并重放所有等待中的请求（或至少重试失败的那个）
- 对非幂等请求（如 POST），重放需谨慎——建议只重放 GET/HEAD，其余提示用户手动重试
服务端响应校验与降级处理
不能只依赖前端 Token 有效期，要结合服务端实际返回判断鉴权状态。
- 监听响应状态码（401、403）和自定义响应头（如
X-Auth-Required: true或X-Token-Expired: true）做精准识别 - 某些场景下服务端会返回新 Token（如刷新成功响应体中含
new_token字段），需提取并更新本地状态 - 提供无 Token 的“游客模式”兜底逻辑：部分接口允许无鉴权访问，此时跳过 Header 注入，避免因 Token 异常导致整个页面不可用
不复杂但容易忽略。核心是把 Token 当作有生命周期的状态来管理，而不是一串静态字符串。
