javascript中ajax默认自动跟随重定向，无法直接捕获；fetch可通过redirect:'manual'拦截并检测response.redirected及location头，xhr则需对比responseurl或依赖服务端自定义header。
JavaScript 中的 Ajax 默认会自动跟随 HTTP 重定向（301、302 等），所以你通常 收不到重定向响应本身，而是直接拿到最终跳转后返回的内容和状态码（比如 200）。这意味着你无法在前端直接捕获“发生了重定向”这一事件，除非主动禁用自动跳转。
如何检测或拦截重定向
现代浏览器支持通过 fetch 的 redirect 选项控制重定向行为：
-
使用
redirect: 'manual'：当服务器返回 301/302 时，fetch 不再自动跳转，而是把响应对象返回给你，此时response.redirected === true，且response.status是 301 或 302，response.headers.get('Location')可读取目标地址。 -
使用
redirect: 'error'：遇到重定向就直接 reject，适合必须禁止跳转的场景（如 API 调用要求严格路径）。 -
默认
redirect: 'follow'（不显式设置时）：自动跳转，你看到的是最终响应，response.redirected为 false，response.url是最终 URL，但原始重定向过程不可见。
XMLHttpRequest 怎么处理重定向
XHR 没有类似 fetch 的 redirect 控制选项，它始终自动跟随重定向。但你可以通过一些间接方式判断：
- 对比
request.responseURL和原始请求 URL：如果两者不同，大概率发生了重定向（注意：某些代理或跨域限制下可能为空）。 - 监听
readystatechange并检查status：虽然你收不到 302 响应，但如果最终响应是 200 但内容异常（比如返回了登录页 HTML），可能是被重定向到了登录页——这属于业务逻辑层面的“隐式重定向”，需结合响应体或 header（如X-Redirected-From）判断。 - 服务端配合：让后端在重定向响应中添加自定义 header（如
X-Redirect-Reason: auth_required），并在最终响应里透传，前端据此识别。
常见状态码的合理判断逻辑
不要只看 status === 200 就认为成功。真实项目中应分层判断：
-
网络层失败：fetch 抛错（如网络断开、CORS 拒绝）、XHR 的
status === 0（常表示请求未发出或被拦截）。 - HTTP 错误状态：4xx 表示客户端问题（如 401 未授权、403 禁止、404 不存在），5xx 表示服务端问题（如 500、503）。建议统一处理：对 401/403 触发登出或跳登录页；对 404 提示资源不存在；对 5xx 显示“服务暂时不可用”。
-
业务态失败：即使 status 是 200，也要解析响应体中的 code 字段（如
{ code: 40001, msg: "token 过期" }），这类约定需前后端对齐。
fetch 示例：手动处理重定向
以下代码演示如何捕获重定向并做决策：
fetch('/api/data', {
redirect: 'manual'
})
.then(response => {
if (response.redirected) {
console.log('重定向到：', response.url);
console.log('Location header：', response.headers.get('Location'));
// 可选择手动跳转：window.location.href = response.url;
// 或携带新 URL 发起二次请求
} else if (response.ok) {
return response.json();
} else {
throw new Error(`HTTP ${response.status}`);
}
})
.catch(err => {
// 处理网络错误、跨域失败、或 redirect: 'error' 触发的 reject
console.error('请求失败：', err);
});
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
