typeerror: failed to fetch 表示请求未达http响应阶段即中断，response对象未生成，主因包括cors拦截、网络层中断、https混合内容限制、file://调试问题及service worker干扰。
TypeError: Failed to fetch 表示 fetch 请求在抵达 HTTP 响应阶段前就中断了，response 对象根本没生成，所以 status、ok、statusText 全部不可读。它不是服务器返回的 4xx/5xx，而是浏览器网络栈或安全策略主动终止的结果。识别它对应哪类底层问题，关键看错误发生时的上下文线索，而不是仅靠错误字符串本身。
看 Network 面板中的请求状态和类型
打开 Chrome DevTools 的 Network 标签页，复现错误后观察失败请求的细节：
- 如果状态显示 failed，类型是 Other 或空白，且没有响应头 —— 大概率是网络层中断（DNS 失败、TLS 握手失败、连接被重置）或协议拒绝（如混合内容）；
- 如果状态显示 (canceled)，且前面有个 OPTIONS 请求也 failed —— 很可能是预检请求被 CORS 拦截；
- 如果主请求状态是灰色、无时间戳、Network 面板里几乎不留下痕迹 —— 常见于
file://协议下运行页面，或被浏览器扩展静默拦截（如广告过滤器标记为net::ERR_BLOCKED_BY_CLIENT）； - 如果请求出现在面板中但状态码列为空，同时控制台出现 “CORS policy” 字样 —— 尽管错误仍是 TypeError，但根源已指向服务端 CORS 响应头缺失或不匹配。
检查 URL 协议与当前页面是否一致
HTTPS 页面中用 fetch 调 HTTP 接口，浏览器会直接终止请求，不发包也不留日志，只抛 TypeError。这类混合内容限制非常隐蔽：
- 确认你代码里写的 URL 是
https://开头，而非http://； - 注意相对路径（如
/api/user）会继承当前页面协议，若页面是https://，那它就是 HTTPS 请求；但若你在本地双击 HTML 文件打开（file://），相对路径可能被解析成file://下的本地路径，导致跨源失败； - 在地址栏手动把
http改成https后刷新页面，再试一次 fetch，能快速验证是否为混合内容问题。
排除 Service Worker 和浏览器扩展干扰
Service Worker 可以劫持 fetch 请求，若其内部逻辑出错（如未处理的 reject、cache.match 抛异常），也可能让外层 fetch 失败并抛 TypeError；浏览器扩展则常在请求发出前就拦截：
- 在无痕窗口（Incognito）中打开页面并复现 —— 无痕模式默认禁用所有扩展；
- 进入 chrome://serviceworker-internals/，找到对应页面的 SW，点击 “Unregister”，再刷新测试；
- 右键失败请求 → “Copy as fetch” → 粘贴到控制台执行，绕过 JS 逻辑和 SW，若仍失败，说明是纯网络或安全层问题。
凭 credentials 配置反向验证 CORS 场景
如果你的 fetch 显式设置了 credentials: 'include' 或 'same-origin'，但服务端没返回 Access-Control-Allow-Credentials: true，浏览器会在预检通过后、主请求发出前就拒绝，报 TypeError：
- 临时改成
credentials: 'omit'（默认值）再试，如果成功，基本锁定是凭据相关 CORS 问题； - 此时需检查服务端是否对带凭据的请求，同时设置了
Access-Control-Allow-Origin（不能是*）和Access-Control-Allow-Credentials: true； - 注意：即使 origin 匹配，只要缺少后者，主请求也不会发出。
