fetch 设置 redirect: 'manual' 时无法获取重定向地址，因浏览器将响应设为 opaque 类型，headers 不可读、status 为 0；应由后端返回 json 指令（如 {redirect: true, url: "..."}），前端手动跳转。
JavaScript 中无法在接口调用中直接响应服务器下发的重定向指令（如 HTTP 302/307），因为 fetch 和 XMLHttpRequest 默认会自动跟随重定向，且不暴露中间重定向响应；而手动禁用自动重定向后，浏览器出于安全限制，又禁止前端 JavaScript 读取重定向目标 URL（response.url 可读但 response.headers.get('Location') 在跨域时为空，同域时也受 CORS 策略影响）。
为什么 fetch 无法获取重定向地址
当设置 redirect: 'manual' 时：
- 若响应是重定向（如 302），
fetch返回一个“opaqueredirect”类型的响应，其 status 始终为 0，headers 为空，body 不可读，无法提取Location头； - 即使同源请求，Chrome/Firefox 也强制将重定向响应封装为 opaque 类型，
response.headers不可访问； - 这是浏览器的安全策略（防止通过重定向泄露敏感跳转逻辑或认证信息），不是 API 缺陷。
可行的替代方案
如果业务确实需要感知或干预重定向（例如统一登录跳转、审计跳转链路、处理 OAuth 回调等），应避免依赖前端解析 HTTP 重定向，改用以下方式：
-
服务端透传跳转意图：后端不返回 3xx，而是返回 200 + JSON，例如：
{ "redirect": true, "url": "/auth/login?return_to=/dashboard" }，前端收到后手动window.location.href = data.url； - 预检式请求：对关键接口（如登录、支付）先发 HEAD 或 OPTIONS 请求，后端在非重定向响应中携带跳转提示字段；
-
使用 iframe 或表单提交绕过 fetch 限制：对于必须触发真实重定向的场景（如 SSO 登录），用
<form method="POST" action="/login"></form>提交，由浏览器原生处理重定向，无需 JS 干预； -
Service Worker 拦截（高级场景）：在支持 SW 的环境中，可在
fetch事件中捕获重定向响应并改写，但需注意兼容性和权限（HTTPS 环境、用户已授权）。
常见误区提醒
以下做法无效或存在隐患：
- 试图用
response.redirected判断是否发生了重定向 —— 它只表示本次 fetch 是否经历了重定向过程，但无法得知跳向哪； - 在
redirect: 'manual'下尝试读取response.headers.get('Location')—— 同域下可能返回 null，跨域下必然不可读； - 用
response.url反推重定向目标 —— 它返回最终到达的 URL（自动跟随后），无法区分中间跳转步骤，且在manual模式下该字段无意义。
推荐实践总结
前端应把重定向视为“浏览器行为”，而非“可编程响应”。真正需要控制跳转逻辑时，让后端配合返回结构化指令，前端负责执行。这样既规避浏览器限制，又提升可测性与错误处理能力。例如登录接口统一返回：
{ "code": 401, "message": "未登录", "redirect_url": "/login?from=%2Fapi%2Fprofile" }
前端检查 redirect_url 字段存在即跳转，否则走常规错误流程 —— 简单、可靠、全平台兼容。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
