fetch 默认不自动处理401，因其非重定向状态码；需手动检查response.status并跳转登录页，同时注意credentials配置与避免跳转循环。
Fetch 默认不会自动处理 401 状态码的重定向——因为 401 不是重定向状态码（如 301/302），而是认证失败提示。所谓“401 重定向”，实际是业务逻辑中遇到 401 后主动跳转登录页。关键在于：拦截响应、判断状态、触发跳转，而非依赖浏览器自动重定向。
识别并拦截 401 响应
Fetch 返回的 Promise 在网络错误时才 reject；HTTP 状态码（包括 401）属于“成功响应”，需手动检查 response.status：
- 调用
fetch()后，先用response.ok或response.status === 401判断 - 不要等
response.json()或其他解析方法后再检查——401 响应体可能为空或无效 JSON - 示例：
if (!response.ok && response.status === 401) { handleAuthError(); }
统一在请求层拦截 401
避免每个 fetch 调用都重复写判断逻辑，推荐封装一个基础请求函数：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 内部统一检查 status，对 401 主动抛出自定义错误（如
throw new Error('UNAUTHORIZED')） - 或直接在函数内执行跳转：
window.location.href = '/login?redirect=' + encodeURIComponent(window.location.pathname) - 若用 React/Vue 等框架，可结合全局状态（如 auth store）清除 token 并导航
注意 credentials 和重定向行为
Fetch 的 redirect 选项控制的是 3xx 响应的自动跟随，与 401 无关，但会影响认证流程：
- 确保请求携带凭证：
credentials: 'include'（Cookie）或手动加Authorization头 -
redirect: 'manual'会阻止 3xx 自动跳转，便于你自行处理（比如登录后回原页） - 服务端返回 401 时，不应同时返回 Location 头——这不符合 HTTP 语义，易引发混淆
避免无限循环跳转
登录页本身若也调用受保护 API（如获取登录配置），可能再次触发 401，导致循环跳转：
- 对已知无需鉴权的路径（如
/login、/public/*）跳过 401 拦截 - 添加标记位或 URL 参数（如
?auth-check=skip）临时禁用拦截 - 前端路由守卫（如 Vue Router 的 beforeEach）可提前判断当前路径是否允许未登录访问
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
