遇到401错误应捕获并检查status码，统一封装apifetch函数自动携带认证头、拦截401后清除token并跳转登录；若支持refresh token，则需防并发刷新、暂存重试队列并安全存储refresh token。
遇到 401 错误，说明请求缺少有效凭证或凭证已过期，核心是捕获错误、检查状态码、触发登录流程（或刷新令牌），而不是直接报错中断。
用 fetch 捕获并识别 401
fetch 默认不会因 HTTP 状态码（如 401）抛异常，需手动检查 response.ok 或 response.status：
- 判断
response.status === 401是最直接可靠的方式 -
response.ok为false时也需进一步确认是否为 401，避免把 500 等其他错误误判 - 示例中建议统一处理响应体（如
response.json()），但注意 401 响应体可能为空或格式不同，加try/catch更稳妥
拦截所有请求：用自定义封装函数统一处理
不推荐在每个 fetch 调用处重复写 401 处理逻辑。可封装一个 apiFetch 函数：
- 自动携带认证头（如
Authorization: Bearer xxx） - 响应后检查 status，若为 401，清除本地 token、跳转登录页（或弹登录框）
- 支持可选的
onUnauthorized回调，便于不同场景定制行为（如管理后台静默跳转，小程序弹窗）
配合 token 刷新机制（进阶）
如果后端支持 refresh token，401 后可尝试自动续期，避免用户频繁重新登录：
- 收到 401 后，先用 refresh token 请求新 access token
- 刷新成功则重发原请求；失败再走登出流程
- 注意防重复刷新（加锁）、并发请求拦截（暂存待重试队列）
- 前端需安全存储 refresh token（如 httpOnly cookie 更佳，localStorage 存在 XSS 风险）
Axios 用户：利用响应拦截器
若使用 Axios，响应拦截器是处理 401 的标准位置：
- 在
axios.interceptors.response.use(..., error => {...})中判断error.response?.status === 401 - 拦截后调用
logout()或showLoginModal()，并返回Promise.reject(error)避免后续 .catch 重复处理 - 可结合
axios.isCancel()排除取消请求，避免误触发登出
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
