浏览器遇到302响应时不会执行HTML或JavaScript，因重定向由HTTP协议层自动完成；唯一能处理302的前端方式是fetch配合redirect: 'manual'，否则只能由服务端返回200页面模拟跳转。
浏览器遇到 302 Found 响应时，**不会执行你写的任何 HTML 或 JavaScript**——重定向由 HTTP 协议层自动完成，前端代码根本没机会运行。
为什么写个 HTML 页面无法“拦截”或“自定义”302
302 是服务器返回的 HTTP 状态码，发生在网络请求响应阶段，早于 HTML 解析和 JS 执行。哪怕你返回的响应体里写了完整的 HTML 页面、甚至带 setTimeout 或 window.location，浏览器也只按 Location 响应头跳转，忽略全部内容。
常见错误现象：
- 在 Nginx/Apache 后端配了 302，却在 HTML 里加
meta http-equiv="refresh"，结果跳了两次 - 用
fetch()请求一个会 302 的接口，但没设redirect: 'manual'，导致拿不到响应头 - 以为在
index.html里写window.location.replace()就能模拟 302，其实这只是前端跳转，状态码仍是 200
需要前端参与的 302 场景：fetch + redirect: 'manual'
只有显式控制 fetch 行为时，才能让 JS 拿到 302 响应本身（否则默认自动跟随）。关键点是设置 redirect 选项：
立即学习“前端免费学习笔记（深入）”；
fetch('/api/old-path', {
redirect: 'manual' // 必须显式指定
})
.then(res => {
if (res.status === 302) {
const location = res.headers.get('Location');
console.log('将跳转到：', location);
// 此处可埋点、做权限判断、或手动跳转
window.location.href = location;
}
});
注意：
-
redirect: 'manual'下，res.body为空，不能读取响应体 - Chrome/Firefox 支持该模式；Safari 对某些跨域 302 可能仍自动跳转
- 不适用于页面初始加载（
<link>、<script src>、地址栏输入），只适用于 fetch/XHR
真正要“处理 302 页面”的唯一合法方式：服务端响应
如果你希望用户看到一个带 UI 的过渡页（比如“正在跳转到新地址…”），就必须让服务端**不返回 302**，而是返回 200 OK + 自定义 HTML 页面，并在其中用前端逻辑跳转：
- Nginx 示例：
return 200 '<html><script>location.href="/new-path"</script></html>'; - Node.js Express：
res.status(200).send('<p>稍等，正在跳转...</p><script>location.href="/new-path"</script>'); - 避免用
meta refresh，因部分浏览器不支持或延迟不可控
这种方案本质是“伪装 302”，实际状态码是 200，所以能执行 JS、展示样式、上报行为——但要注意 SEO 影响（搜索引擎不认为这是重定向）。
容易被忽略的兼容性细节
有些老系统或内嵌 WebView（如微信 X5 内核、某些银行 App）对 Location 头解析异常严格：
- 值必须是绝对 URL（
https://example.com/path），相对路径（/path）可能失败 - 部分客户端会忽略空格或换行符后的
Location头，确保后端输出无多余空白 - 如果重定向链过长（>20 跳），Chrome 会直接报
ERR_TOO_MANY_REDIRECTS，且不触发任何 JS
真要调试 302 流程，别盯着 HTML 看，打开 DevTools 的 Network 面板，选中请求，看 Headers 标签页里的 Status 和 Location ——那才是唯一真实发生的事。
