Service Worker是一种运行在浏览器后台的独立线程，它能够拦截页面发出的网络请求、管理缓存并实现离线可用。借助JavaScript注册Service Worker后，网页即使断开网络也能从本地缓存读取资源，这对提升弱网体验和构建PWA至关重要。
一、Service Worker基础概念
Service Worker本质上是一个特殊的JavaScript文件，由浏览器在独立线程中执行，不阻塞页面主线程，也无法直接操作DOM。它充当了网页与网络之间的代理层，所有符合条件的请求都会先经过它的处理。这种设计使得开发者可以精细控制每一个资源的获取方式，比如优先使用缓存、走网络或者在二者之间做权衡。
与传统的Web Worker不同，Service Worker具有持久性，即使页面关闭，它也可能保留在浏览器中处理推送通知或后台同步。但它也受到严格的安全限制：必须在HTTPS环境下使用（本地开发时localhost除外），且注册的作用域决定了它能控制哪些页面。这些约束是浏览器出于安全考虑所做的设计，避免恶意脚本拦截用户流量。
二、注册与生命周期
使用JavaScript启用Service Worker的第一步是调用navigator.serviceWorker.register方法，指定Worker脚本路径。浏览器下载并解析脚本后，会触发install事件，通常在这个阶段使用Cache API预缓存核心资源。安装成功后进入waiting状态，待旧Worker释放后激活，触发activate事件，可用于清理过期缓存。
下面是一个最简单的注册示例，展示了如何捕获注册失败的情况，并在安装阶段缓存基础文件：
// 注册Service Worker
if ('serviceWorker' in navigator) {
window.addEventListener('load', function () {
navigator.serviceWorker.register('/sw.js').then(function (reg) {
console.log('注册成功，作用域为：', reg.scope);
}).catch(function (err) {
console.log('注册失败：', err);
});
});
}
在sw.js中，我们监听生命周期事件并完成缓存逻辑。注意cache名称带上版本号，方便后续更新时清理旧缓存：
const CACHE_NAME = 'v1-offline';
const URLS = ['/', '/index.html', '/style.css', '/app.js'];
self.addEventListener('install', function (event) {
event.waitUntil(
caches.open(CACHE_NAME).then(function (cache) {
return cache.addAll(URLS);
})
);
});
self.addEventListener('activate', function (event) {
event.waitUntil(
caches.keys().then(function (keys) {
return Promise.all(
keys.filter(function (k) { return k !== CACHE_NAME; })
.map(function (k) { return caches.delete(k); })
);
})
);
});
三、拦截请求与离线实现
Service Worker最核心的能力体现在fetch事件上。当页面发起请求时，Worker会收到该事件，开发者可以决定是从缓存返回、发往网络还是采用其他策略。最常见的离线方案是缓存优先：先查Cache API，命中则直接返回，未命中再请求网络并写入缓存。
以下代码展示了缓存优先配合网络回退的逻辑，同时演示了如何转义HTML特殊字符以避免语法错误：
self.addEventListener('fetch', function (event) {
event.respondWith(
caches.match(event.request).then(function (response) {
if (response) {
return response;
}
return fetch(event.request).then(function (res) {
// 只缓存同源且成功的GET请求
if (res && res.status === 200 && res.type === 'basic') {
var copy = res.clone();
caches.open(CACHE_NAME).then(function (cache) {
cache.put(event.request, copy);
});
}
return res;
}).catch(function () {
// 离线且缓存未命中时返回兜底页面
return caches.match('/index.html');
});
})
);
});
在上面的代码中，我们使用res.clone()是因为响应流只能被读取一次，缓存和返回需要两份副本。传统误区是认为localStorage可以存离线页面，但localStorage仅能存字符串且容量小，而Cache API专门设计用来存储请求和响应对象，体积更大也更高效。
四、更新机制与常见坑点
Service Worker的更新依靠浏览器重新下载sw.js文件。当文件内容发生变化，浏览器会安装新Worker，但旧Worker仍控制页面直到所有页面关闭。这就是很多人修改代码后离线效果未生效的原因。可以在activate阶段调用self.skipWaiting()和clients.claim()强制立即接管。
另一个常见问题是作用域限制。若注册路径为/foo/sw.js，则它只能控制/foo/下的页面。若想扩大范围，需要通过Service-Worker-Allowed响应头授权。此外，开发时若使用http而非localhost，注册会直接报错，这是浏览器安全策略决定的，部署时必须使用HTTPS。
| 策略 | 优点 | 缺点 |
|---|---|---|
| 缓存优先 | 离线极快，弱网体验好 | 可能返回旧内容 |
| 网络优先 | 内容实时性强 | 离线时完全不可用 |
| stale-while-revalidate | 兼顾速度与更新 | 逻辑稍复杂 |
五、总结与实践建议
通过JavaScript结合Service Worker与Cache API，前端可以低成本实现真正的离线应用。建议将核心壳资源在install阶段预缓存，动态数据采用运行时缓存，并设计清晰的版本与清理规则。对于包含表单提交的场景，还可配合后台同步API在恢复网络后补发数据。
在开发过程中，利用浏览器开发者工具的Application面板可以直观查看Worker状态与缓存内容。只要理清生命周期、作用域和请求拦截三者关系，就能避开绝大多数坑，让网页在地铁、电梯等弱网环境中依然流畅可用。
Service_Worker离线应用JavaScript修改时间：2026-08-03 09:36:31