请求拦截器自动携带有效Access Token至Authorization头（避开/login等接口）；响应拦截器捕获401后，通过isRefreshing标志、requestQueue队列和刷新逻辑实现静默续期，失败则清空凭证跳转登录。
请求拦截器：自动携带 Access Token
每次发请求前，检查本地是否有有效的 Access Token。如果有，就加到 Authorization 请求头里，格式为 Bearer {token}。注意避开登录、刷新等特殊接口（比如 /login 或 /refresh），这些接口不该带业务 token。
响应拦截器：捕获 401 并触发刷新逻辑
收到响应后，先看状态码是不是 401，再确认这个请求不是刷新 Token 的请求（可通过自定义字段如 config.__isRefreshToken 标识）。满足这两个条件，就说明 Access Token 已过期，需要静默刷新。
关键点有三个：
- 用 isRefreshing 标志位防止多个 401 同时触发多次刷新请求
- 把后续等待中的请求暂存进 requestQueue 队列
- 调用刷新接口，传入当前的 Refresh Token，拿到新 Access Token 后更新本地存储
刷新成功后重试失败请求
新 token 存好后，遍历队列里的每个请求配置，更新其 Authorization 头为新 token，再用 axios 重新发起请求。队列清空，标志位重置，整个过程对用户完全透明。
立即学习“前端免费学习笔记（深入）”；
如果刷新接口返回失败（比如 403 或网络异常），说明 Refresh Token 也失效了，这时应清空所有本地凭证，跳转登录页。
并发场景下的安全处理
当多个请求几乎同时返回 401，只允许第一个进入刷新流程，其余请求挂起等待。等新 token 落地后，统一用新凭证重试——避免重复刷新、token 覆盖错乱或请求乱序。
实现上常用 Promise 链式等待：队列中每个待重试项是一个函数，接收新 token 作为参数并执行重发；刷新完成后，Promise.all(requestQueue.map(fn => fn(newToken))) 即可批量恢复。
