ServiceWorker 的 fetch 事件仅拦截同源且页面主动发起的请求（如 fetch、XMLHttpRequest、img 等），不拦截 iframe、跨域无 CORS 的资源、sendBeacon 及 SW 自身安装请求。
ServiceWorker 的 fetch 事件能拦截哪些请求
ServiceWorker 的 fetch 事件只拦截同源的、由页面主动发起的网络请求（包括 fetch()、XMLHttpRequest、、 等），但不拦截：iframe 加载、跨域不带 CORS 头的图片/字体、navigator.sendBeacon()、以及 ServiceWorker 自身安装阶段的脚本请求（即 self.registration.update() 不触发自身 fetch）。
在 fetch 事件里怎么读取和修改请求数据
关键点是：不能直接修改 request 对象（它是只读的），必须用新构造的 Request 替换；响应体需用 Response 构造，且若要读取原始响应内容（如 JSON），得先调用 response.clone().json() 或 .text()——否则原 response 会被消耗掉，无法再返回。
-
event.request.url和event.request.method可用于路由判断 - 改写 URL 需用
new Request(newUrl, { method, headers, body }) - 转发请求推荐用
fetch(event.request)，不是fetch(event.request.url)（会丢失 method/body/headers） - 若需缓存并返回，记得设置
headers: { 'Content-Type': 'application/json' }，否则浏览器可能解析失败
self.addEventListener('fetch', event => {
const url = new URL(event.request.url);
if (url.pathname === '/api/data') {
event.respondWith(
fetch(new Request('https://mock-api.example.com/data', {
method: event.request.method,
headers: event.request.headers,
body: event.request.body
}))
.then(res => {
const cloned = res.clone();
return Promise.all([
cloned.json(),
Promise.resolve(res)
]).then(([data, realRes]) => {
console.log('拿到数据:', data);
return realRes;
});
})
);
}
});
fetch 事件中常见错误和绕不过的坑
最常踩的三个坑：缓存策略误用导致接口永远不更新、event.respondWith() 没调用或调用多次、对流式响应（如 text/event-stream）做 .json() 解析直接报错。
- 没调用
event.respondWith()→ 请求会走默认网络，但控制台可能无提示 - 重复调用
respondWith()→ 报错Failed to execute 'respondWith' on 'FetchEvent': The event has already been responded to - 对非 JSON 响应调
.json()→Unexpected token或空对象 - 使用
cache.match()后直接return cacheRes→ 缺少headers导致 CORS 失败，应return new Response(cacheRes.body, cacheRes)
如何调试 ServiceWorker 的 fetch 拦截行为
Chrome DevTools 的 Application → Service Workers 面板可「Skip waiting」「Update on reload」，但真正看拦截细节得靠 console.log + 网络面板过滤 Other 类型请求（因为 SW 返回的响应不显示为 XHR/fetch，而是归为 Other）。更可靠的方式是在 SW 里加日志并配合 chrome://serviceworker-internals/ 查看运行状态。
立即学习“前端免费学习笔记（深入）”；
- 在 SW 顶部加
self.addEventListener('activate', e => console.log('SW activated'))确认激活成功 - fetch 事件里打日志时用
console.log('[SW fetch]', event.request.url, event.request.method) - 若请求没进 fetch 事件，先检查是否注册成功、是否在 HTTPS（或 localhost）、是否页面在 SW 控制范围内（
navigator.serviceWorker.controller !== null）
fetch 是强大但脆弱的机制，真正难的不是写几行拦截逻辑，而是确保每次响应都携带正确 headers、不破坏原始语义、且在离线/缓存/网络三态间保持行为一致。尤其注意流式响应、重定向、认证头（Authorization）透传这些边界情况，它们往往在灰度期才暴露。 
