fetch 的 redirect 配置决定 3xx 响应的处理方式：follow 默认自动跳转但隐藏中间过程且不携带认证头；error 主动拒绝跳转适用于强校验；manual 返回原始重定向响应供自定义处理。

Fetch 的 redirect 配置决定请求遇到 3xx 状态码（如 301、302、307、308）时的行为，不是“要不要跳”，而是“谁来跳、怎么跳、跳了之后还能不能看到中间过程”。默认是自动跟随，但实际开发中常需干预——尤其在登录跳转、接口代理、审计重定向链等场景。

redirect: "follow"（默认行为，但要注意隐含限制）

这是最常用也最容易被误解的选项。它让 Fetch 自动发起后续请求，最终返回终点响应：

• 你拿到的 response.url 是最终地址，中间跳转 URL 完全不可见；
• Cookie 和 Authorization 头只在初始请求携带，重定向后的请求不会自动带上（即使同域）；
• 304（Not Modified）不被视为重定向，不受 redirect 参数控制；
• 跨域重定向（比如从 a.com → b.com）在 CORS 模式下大概率失败，浏览器会拦截，返回 opaque 响应或直接报错。

redirect: "error"（主动中断，适合强校验）

只要服务器返回任意 3xx 状态码，Promise 就立刻 reject，并抛出 TypeError（不是网络错误，而是类型错误）：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 适合调试阶段验证接口是否被意外代理、网关或 CDN 重写；
• 适用于必须直连源站的敏感操作（如支付回调确认、token 刷新）；
• 缺点是无法获知重定向目标，仅能知道“发生了跳转”，没法做日志或降级处理。

redirect: "manual"（完全掌控，用于自定义逻辑）

Fetch 不自动跳，而是返回原始重定向响应（如 status=302），把决策权交给你：

• response.redirected 为 true，且 response.headers.get("Location") 可读取跳转地址；
• 你可以检查 Location 是否合法（比如是否同源、是否白名单路径）；
• 可手动添加认证头、限制最多跳 3 次、记录跳转链用于埋点；
• 注意：此时 fetch 新请求仍需显式设置 credentials（如 include），否则 Cookie 不会发送。

配合后端重定向的实用建议

服务端用 Response.Redirect 返回 302，前端 fetch 默认不会跳转到新页面——它只是拿到一个 302 响应对象。所以：

• 推荐后端改返回 JSON（如 {"redirect":"/dashboard"}），前端用 window.location.href 跳，更可控、兼容性好；
• 若必须保留 302，前端应设 redirect: "manual"，再解析 Location 并调用 fetch(newUrl) 或跳转；
• 不要依赖 redirect: "follow" 实现前端路由跳转，它只影响 fetch 请求链，不影响浏览器地址栏。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南