HTML5怎样用ServiceWorker拦截请求取数据_HTML5SW请求取法【枚举】

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）

ServiceWorker 的 fetch 是强大但脆弱的机制，真正难的不是写几行拦截逻辑，而是确保每次响应都携带正确 headers、不破坏原始语义、且在离线/缓存/网络三态间保持行为一致。尤其注意流式响应、重定向、认证头（Authorization）透传这些边界情况，它们往往在灰度期才暴露。