Service Worker 是运行在浏览器后台的事件驱动型脚本，用于拦截请求、管理缓存、实现离线应用；需 HTTPS 注册，经历 install→wait→activate 生命周期，配合 Cache API 和 fetch 事件实现缓存策略与版本更新。
Service Worker 是运行在浏览器后台的脚本，独立于网页主线程，能拦截网络请求、管理缓存、推送通知，是实现离线应用的核心机制。
Service Worker 的本质和生命周期
它不是普通 JS 脚本，而是一个可被注册、安装、激活的事件驱动型 worker。必须通过 HTTPS（本地 localhost 除外）启用，且只能控制同源页面。注册后，浏览器会尝试安装它；安装成功后进入等待状态；当旧 Service Worker 不再控制页面时，新版本才被激活。
- 注册需在主页面中调用 navigator.serviceWorker.register('./sw.js')
- 安装阶段通常预缓存关键资源（HTML/CSS/JS/图标等）
- 激活后才能接管 fetch 事件，开始拦截请求
用 Cache API 实现离线资源存储
Service Worker 自带 Cache API，允许显式创建命名缓存、存取 Response 对象。它和 HTTP 缓存互不干扰，完全由开发者控制。
- 安装时用 caches.open('v1').then(cache => cache.addAll([...])) 预加载静态资源
- 激活时可清理旧缓存：caches.delete('v0')
- 缓存键是完整的 request URL，匹配时注意 query 参数和 header 差异
拦截请求并智能返回缓存或网络
在 activate 后，Service Worker 可监听 fetch 事件，决定每个请求走缓存、网络，还是两者结合（如缓存优先 + 后台更新）。
立即学习“Java免费学习笔记（深入）”；
- 缓存优先：先查 caches.match(request)，命中则返回，否则 fetch 网络并存入缓存
- 网络优先：先 fetch，失败时 fallback 到缓存（适合内容常更新但需保底）
- 对 HTML 请求建议用网络优先 + 缓存 fallback，避免陈旧 shell；对静态资源用缓存优先
更新策略与调试要点
Service Worker 不会自动更新已注册的版本。修改 sw.js 文件后，浏览器会在下次页面加载时拉取新文件并触发 install → wait → activate 流程，但旧版本仍控制当前打开的页面。
- 调试时可在 Chrome DevTools > Application > Service Workers 中勾选 “Update on reload”
- 调用 self.skipWaiting() 可跳过 waiting 状态，让新版本立即激活（需配合 clients.claim() 控制当前页面）
- 避免在 fetch 事件中直接 return fetch() 而不处理 reject，否则离线时页面空白
基本上就这些。Service Worker 本身不复杂，但缓存逻辑、版本控制和请求策略容易忽略细节，实际做离线应用时，关键是理清哪些资源必须离线可用、何时更新、如何降级。
