Service Worker 是浏览器后台脚本，核心用于实现离线体验：通过 install 阶段预缓存资源、fetch 阶段拦截请求并策略化响应、导航失败时返回 offline.html，并支持后台同步与页面通信，需注意 HTTPS 依赖、版本更新机制及缓存策略合理性。

Service Worker 是浏览器在后台运行的脚本，它充当网页与网络之间的“代理”，让开发者能精细控制网络请求、缓存策略和推送通知。最核心的用途是实现可靠的离线体验——用户断网后仍能打开页面、加载资源、甚至使用部分功能。

拦截并缓存网络请求

Service Worker 可以监听 fetch 事件，在请求发出前决定是走网络、读缓存，还是返回兜底内容。关键在于主动缓存静态资源（如 HTML、CSS、JS、图片），并在安装阶段预填充缓存。

• 在 install 阶段调用 caches.open() 创建缓存，并用 cache.addAll() 预缓存关键文件
• 在 fetch 阶段检查请求是否命中缓存；命中则直接返回，未命中再发网络请求，并把响应存入缓存（可选）
• 注意：HTML 文件通常不建议长期缓存，应采用“网络优先，失败降级到缓存”策略，避免版本不一致

支持离线时的页面加载

要让用户在无网时打开首页或任意路由仍能显示内容，需缓存一个“离线页”（offline.html），并在 fetch 中对导航请求（request.destination === 'document'）做特殊处理。

• 安装时缓存 offline.html 和主页面 shell（如 index.html）
• fetch 事件中，若请求是页面导航且网络失败，用 cache.match('/offline.html') 返回离线页
• 配合 Cache-Control 响应头和缓存命名策略（如按版本号命名 cacheName），便于后续更新缓存

实现后台同步与消息通信

Service Worker 还能配合 Background Sync API 在网络恢复后自动重发待办请求（如表单提交），并通过 postMessage 与页面双向通信。

• 页面调用 navigator.serviceWorker.register('sw.js') 注册后，可用 registration.active.postMessage() 向其发送指令
• Service Worker 中监听 message 事件，执行对应逻辑（如清空缓存、触发同步）
• 需注意：Service Worker 可能被终止，不保证长期驻留，因此耗时操作应拆解或交由页面协调

注意事项与常见坑点

Service Worker 依赖 HTTPS（本地 localhost 除外），且生命周期独立于页面。调试时容易因旧版本残留导致行为异常。

• 每次修改 sw.js 后，浏览器会尝试安装新版本，但旧版本仍控制着已打开的页面；需调用 skipWaiting() 并 clients.claim() 让新 SW 立即生效
• 缓存策略不是越激进越好：过度缓存 HTML 或 API 接口会导致数据陈旧；推荐对静态资源用 Cache-First，API 用 Network-First
• 不支持 window、document 等 DOM 对象，所有操作基于 fetch、caches、indexedDB 等异步 API

不复杂但容易忽略：注册 Service Worker 只是第一步，真正决定离线体验的是你如何设计缓存范围、更新时机和降级逻辑。