Fetch 不会直接抛 ERR_TOO_MANY_REDIRECTS 错误，但默认 follow 模式受浏览器重定向上限（通常20次）制约，超限则 Promise reject 并报 TypeError；manual 模式可主动监控跳转链、防循环、限次数，配合服务端排查与降级策略规避风险。
Fetch 本身不会直接抛出 ERR_TOO_MANY_REDIRECTS 这类浏览器级错误，但它会在重定向链超出限制时自动终止，并返回一个失败的 Promise——具体表现取决于 redirect 配置。真正触发“重定向次数过多”的是浏览器底层（通常限制为 20 次），而 Fetch 默认的 follow 行为会受此制约。
浏览器自动限制重定向次数
当服务器返回连续重定向（如 302 → 302 → …），且跳转次数超过浏览器上限（Chrome/Firefox 一般为 20 次），fetch 请求会直接失败，Promise 被 reject，错误信息类似：
-
TypeError: Failed to fetch（无详细原因） - 控制台可能显示
net::ERR_TOO_MANY_REDIRECTS - response 对象不可用，无法读取 status 或 headers
用 manual 模式主动监控跳转链
若需提前发现循环或超限风险，应禁用自动跳转，改用 redirect: "manual"，自己记录和判断跳转次数：
- 每次收到
response.redirected === true时，解析Location头 - 维护一个跳转路径数组，检查是否出现重复 URL（如
location.href已存在） - 设置最大跳转次数（例如 5 次），超限时主动 throw 错误并记录
- 注意：手动发起下一次 fetch 时，要显式传入
credentials: 'include'等必要选项
服务端配合排查与降级
前端无法绕过浏览器限制，但可辅助定位问题：
立即学习“Java免费学习笔记（深入）”；
- 在
catch块中检查错误名或消息是否含"ERR_TOO_MANY_REDIRECTS"，用于上报或提示用户“链接异常” - 对关键请求（如登录、支付回调）避免依赖重定向，改用服务端直传目标地址或状态码标识
- 配合后端排查：确认是否有中间网关、CDN、反向代理或认证中间件意外插入重定向
- 临时降级：若检测到多次重定向失败，可切换为 window.location.href 跳转，交由浏览器处理（牺牲体验换可用性）
避免常见诱因
很多“重定向过多”实际源于配置或逻辑错误，可在开发阶段规避：
- 确保前后端协议一致（http/https），避免因协议不匹配引发 301 强制跳转
- 检查认证逻辑：未登录时跳登录页，登录成功后又因 session 未同步跳回原页，形成闭环
- 避免在 Service Worker 中对同一请求反复 rewrite 并 redirect
- 测试时清除浏览器缓存和 Cookie，防止旧重定向规则残留
