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（不是网络错误，而是类型错误）：
- 适合调试阶段验证接口是否被意外代理、网关或 CDN 重写；
- 适用于必须直连源站的敏感操作（如支付回调确认、token 刷新）；
- 缺点是无法获知重定向目标，仅能知道“发生了跳转”，没法做日志或降级处理。
redirect: "manual"（完全掌控，用于自定义逻辑）
Fetch 不自动跳，而是返回原始重定向响应（如 status=302），把决策权交给你：
立即学习“Java免费学习笔记（深入）”；
-
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 请求链，不影响浏览器地址栏。
