Service Worker是运行在主线程外的可编程网络代理,需HTTPS注册、显式缓存资源、拦截fetch事件并提供fallback;不可用localStorage/DOM API,须用cacheStorage、IndexedDB或postMessage;fetch事件必须respondWith,新版本需skipWaiting/clients.claim调试。
Service Worker 本质是一个可编程的网络代理,它运行在浏览器主线程之外,能拦截、修改甚至伪造网络请求。要创建离线应用,关键不是“注册就能离线”,而是必须显式缓存资源 + 拦截 fetch 事件 + 提供 fallback 策略。
浏览器只允许在安全上下文中注册 ServiceWorker。开发时可用 localhost,但部署到真实域名必须启用 HTTPS,否则 navigator.serviceWorker.register() 会静默失败或直接抛 SecurityError。
常见错误现象:Failed to register a ServiceWorker: ServiceWorker script does not exist 或控制台无报错但 registration 为 undefined —— 先检查协议是否为 https:// 或 http://localhost。
window.addEventListener('load', ...) 或页面 DOM 就绪后执行,不能在模块顶层同步调用register() 的路径是相对于站点根目录的,比如 /sw.js,不是 ./sw.js
sw.js 文件内容字节变化时才重新安装新版本ServiceWorker 是一个独立的 worker 线程,没有 window、document、localStorage 等浏览器环境对象。试图读写 localStorage 会直接报 ReferenceError;操作 document.body 会报 undefined is not an object。
替代方案只有三种:
cacheStorage 缓存静态资源(HTML/CSS/JS/图片)IndexedDB 存结构化数据(需在 install 或 activate 阶段初始化)postMessage() 和主页面通信,让页面端处理 DOM 或 storage 逻辑只要注册了 Service Worker,所有同源请求(包括 fetch、XMLHttpRequest、、)都会经过 fetch 事件。但默认行为不是“自动走缓存”,而是“放行到网络”——你必须自己 event.respondWith(...),否则请求会卡住或返回空响应。
典型离线兜底写法:
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request)
.then(cached => cached || fetch(event.request))
.catch(() => caches.match('/offline.html'))
);
});
注意点:
caches.match() 不匹配带动态查询参数的 URL(如 /api/data?id=123),需手动 normalize 或改用 cache.addAll() 预缓存固定路径fetch 事件里直接 return fetch(...) 而不包在 respondWith() 中,这会导致未捕获异常中断请求流新版本 Service Worker 默认不会立即激活:它会等所有旧 tab 关闭后才进入 waiting → active 状态。这意味着你改了 sw.js,但页面仍用老逻辑,容易误判缓存是否生效。
开发阶段建议在 install 事件中加强制激活:
self.addEventListener('install', event => {
event.waitUntil(self.skipWaiting());
});
self.addEventListener('activate', event => {
event.waitUntil(self.clients.claim());
});
但上线前应移除 skipWaiting(),否则可能造成新旧缓存策略冲突(比如新版删了某个缓存 key,但旧 tab 还在读它)。
真正难的不是注册或缓存,而是设计缓存生命周期:哪些资源该长期缓存?API 响应要不要缓存?离线时表单提交怎么暂存?这些没想清楚,光跑通 sw.js 文件加载只是第一步。