ServiceWorker作用及离线使用技巧

Service Worker 是浏览器后台运行的脚本代理，核心价值在于打造可靠、流畅的离线体验：它通过 install 阶段预缓存关键资源、fetch 阶段智能拦截并策略化响应请求（如静态资源缓存优先、HTML网络优先+离线兜底）、导航失败时无缝返回 offline.html，同时支持后台同步重发待办任务和与页面双向通信；但要真正落地，必须直面 HTTPS 依赖、版本更新陷阱、缓存策略失衡等实战难点——离线能力不取决于是否注册了 Service Worker，而在于你如何精细设计缓存范围、更新时机与降级逻辑。

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 只是第一步，真正决定离线体验的是你如何设计缓存范围、更新时机和降级逻辑。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~