ServiceWorker实现离线资源拦截方法

Service Worker 实现离线访问的核心在于精准匹配：必须确保注册时 scope 覆盖目标资源路径、install 阶段用完整绝对路径预缓存关键静态文件（含查询参数和尾部斜杠），并在 fetch 事件中依据 request.destination 和 request.mode 对不同资源类型（如 document、script、cors API）实施差异化缓存策略，同时严格保持 credentials 等请求选项的一致性；绝大多数离线失效并非代码逻辑错误，而是 URL 格式、缓存时机或匹配条件的细微偏差所致——真正可靠的离线体验，源于对每一个请求细节的严谨校验与调试验证。

Service Worker 能拦截静态资源请求并实现离线访问，但前提是它必须已成功注册、激活，并且缓存策略与资源请求的 URL 和 Request.mode 完全匹配——很多失败都卡在这一步，不是代码写得不对，而是缓存时机或匹配逻辑没对上。

注册时确保 scope 和路径权限正确

Service Worker 的作用域（scope）决定了它能拦截哪些请求。默认 scope 是 service worker 文件所在目录及其子目录；若想拦截根路径下的 /css/app.css 或 /img/logo.png，worker 文件必须放在根目录（如 /sw.js），或显式指定 scope: '/'：

navigator.serviceWorker.register('/sw.js', { scope: '/' });

常见错误是把 sw.js 放在 /js/sw.js 却不设 scope，结果它只能拦截 /js/ 下的请求，根本收不到对 /index.html 的 fetch 事件。

install 阶段预缓存关键静态资源

用 cache.addAll() 在 install 事件中批量缓存 HTML、CSS、JS、字体等核心静态资源。注意：这些 URL 必须是完整路径（相对路径会相对于 worker 文件解析），且需与后续 fetch 时发起的请求 URL 严格一致（包括 trailing slash、查询参数）：

• cache.addAll(['/', '/css/app.css', '/js/main.js']) —— 正确，路径与页面实际请求一致
• 误写成 ['index.html', 'css/app.css'] —— 失败，因为浏览器请求的是 /index.html，而缓存的是 index.html（无前导斜杠）
• 若 HTML 中引用了 logo.png?v=2，缓存时也必须带 ?v=2，否则匹配不上

fetch 事件中区分请求类型并精准匹配缓存

不能一概而论“所有 GET 请求都走 cache”，要按 request.destination 或 request.mode 分类处理。例如：

• request.destination === 'document' → 主页面，应优先返回缓存（哪怕过期），再后台更新（stale-while-revalidate）
• request.destination === 'script' || request.destination === 'style' → JS/CSS，建议强制使用缓存（cache.match(request)），避免白屏
• request.mode === 'cors' → 通常是 API 请求，不应走静态缓存，直接 fetch(request)

特别注意：cache.match() 默认只匹配 URL 和 method，若请求带 credentials: 'include'，缓存时也必须用相同选项打开 cache（caches.open('static-v1').then(cache => cache.addAll(...)) 不带 credentials，但 match() 会因 credentials mismatch 失败）。

调试时重点检查 Cache Storage 和 Fetch Event 触发状态

Chrome DevTools 的 Application → Cache Storage 可查看已缓存内容，但注意：缓存条目显示的 URL 是编码后的，比如空格变 %20；而 fetch 事件监听器里打印的 request.url 是解码后的，二者肉眼对比容易误判“没命中”。更可靠的方式是在 fetch 回调开头加：

self.addEventListener('fetch', event => {
  console.log('SW intercepts:', event.request.url, 'mode:', event.request.mode);
  event.respondWith(
    caches.match(event.request).then(res => res || fetch(event.request))
  );
});

然后在 Network 面板勾选 Offline，看哪些请求显示 from ServiceWorker，哪些仍标 failed——标 failed 的，八成是 cache.match() 返回 undefined，原因通常是 URL 不一致、destination 不匹配，或者缓存根本没生效（比如 install 阶段抛错被静默吞掉，此时要查 Console 是否有 unhandled promise rejection）。

离线体验是否可靠，不取决于你写了多少行缓存逻辑，而取决于每一条缓存的 URL 是否和浏览器真实发出的请求完全一致，以及你在 fetch 事件里有没有为不同资源类型设置差异化的兜底策略。

今天关于《ServiceWorker实现离线资源拦截方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！