Service Worker 是运行在浏览器后台的独立 JavaScript 线程，作为事件驱动的代理层拦截并响应网络请求，需 HTTPS 注册、生命周期由浏览器控制；注册后需两次刷新才能完全激活，配合 cache API 与 fetch 事件实现离线能力，缓存更新需手动清理旧版本。
Service Worker 是什么？它不是普通脚本
Service Worker 是运行在浏览器后台的独立 JavaScript 线程，不绑定任何页面，无法访问 document 或 window。它本质是一个**事件驱动的代理层**，拦截、修改、响应网络请求——这是实现离线体验的核心能力。
关键点在于：它必须通过 HTTPS（或 localhost）注册；一旦激活，会持续驻留在浏览器中，即使页面关闭；它的生命周期由浏览器控制，不因页面刷新而重启。
如何注册并激活 Service Worker？注意作用域和刷新陷阱
注册代码必须放在主页面的 JS 中，且只执行一次（重复调用 navigator.serviceWorker.register() 不会重新安装）。常见错误是注册后页面没刷新导致旧缓存仍生效。
- 注册路径决定作用域：
navigator.serviceWorker.register('/sw.js')表示该 Worker 只能控制/及其子路径 - 首次注册后，需手动刷新页面两次才能让新 Worker 完全接管：第一次跳过等待（
skipWaiting），第二次完成激活 - 开发时建议在
sw.js开头加时间戳注释，避免浏览器缓存旧版本
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.register('/sw.js')
.then(reg => console.log('SW registered:', reg.scope))
.catch(err => console.error('SW registration failed:', err));
});
}
cache API + fetch 事件 = 离线核心逻辑
离线能力不靠“预加载全部资源”，而是靠在 install 阶段缓存关键静态资源（HTML/CSS/JS），再在 fetch 事件中优先返回缓存、失败再走网络（或兜底页面）。
立即学习“Java免费学习笔记（深入）”；
-
caches.open('v1')创建命名缓存，不同版本名可实现缓存轮换 -
event.waitUntil()必须包裹异步操作，否则 Worker 可能在任务完成前终止 - 不要在
fetch里无条件return caches.match(event.request)——这会让所有请求都离线，连带阻断 API 更新 - 推荐策略：对 HTML 请求走“网络优先，失败 fallback 到缓存”；对静态资源走“缓存优先”
self.addEventListener('fetch', event => {
const url = new URL(event.request.url);
if (url.pathname === '/' || url.pathname.endsWith('.html')) {
event.respondWith(
fetch(event.request).catch(() => caches.match('/offline.html'))
);
} else {
event.respondWith(
caches.match(event.request).then(res => res || fetch(event.request))
);
}
});
更新缓存时最容易被忽略的三个细节
缓存更新不是自动发生的。Service Worker 脚本内容变更才会触发升级流程，但旧缓存不会自动清除，也不会自动重填新缓存。
- 每次更新
sw.js，必须在install钩子中显式打开新缓存（如'v2'），并用event.waitUntil(caches.delete('v1'))清理旧缓存 - 如果页面长期不关闭，已激活的 Worker 不会自动更新；需监听
controllerchange事件提示用户刷新 - 调试时禁用缓存（DevTools → Application → Service Workers → ✅ “Update on reload”）只是绕过检查，不代表生产行为
离线体验真正的复杂点不在代码多难写，而在于缓存策略和生命周期的耦合——一个没删干净的旧缓存，可能让新版 HTML 一直加载老版 CSS。
