ServiceWorker拦截请求实现离线加载方法

Service Worker 是构建可靠 Web 离线体验的核心技术，它并非简单注册即可生效，而需精心设计缓存策略——对页面导航采用缓存优先+离线兜底、对静态资源坚持缓存优先、对 API 请求则推荐网络优先并智能回退旧数据；同时必须严格管理缓存生命周期（通过版本化缓存名、install 预加载、activate 清理旧缓存），并规避调试陷阱（如禁用 SW 脚本缓存、正确处理 Promise 异常、配置 CORS 支持跨域拦截），才能真正让应用在断网时依然流畅可用。

Service Worker 是实现 Web 应用离线能力的核心机制，它本质是一个可拦截、修改甚至伪造网络请求的脚本，在浏览器后台独立运行，不绑定具体页面。要实现可靠离线化，关键不是“只要注册了就能离线”，而是要主动控制缓存策略、区分资源类型、处理请求失败回退，并兼顾更新与清理逻辑。

注册并激活 Service Worker

必须在 HTTPS（或 localhost）环境下运行；注册代码需放在主页面的 JavaScript 中，且通常只执行一次：

• 调用 navigator.serviceWorker.register('./sw.js') 注册脚本，路径需为同源下的相对或绝对 URL
• 注册后，浏览器会下载、解析并进入 installing 状态；只有当页面所有标签页都不再使用旧版 SW，新 SW 才能跳过 waiting 进入 activated 状态
• 可在 install 事件中预缓存核心静态资源（如 HTML、JS、CSS、图标），用 caches.open().addAll() 批量存入命名缓存

拦截 fetch 请求并智能响应

在 activated 的 Service Worker 中监听 fetch 事件，决定每个请求如何响应：

• 对导航请求（request.destination === 'document'），优先尝试从缓存匹配，未命中则 fallback 到网络；若网络也失败，返回预置的离线 HTML 页面
• 对静态资源（JS/CSS/图片等），可用 cache-first 策略：先查缓存，命中即返回；未命中则发网络请求，成功后写入缓存再返回
• 对 API 接口请求，推荐 network-first：先发网络，成功则缓存响应（注意检查响应状态码和 headers 是否允许缓存）；失败时可返回上一次缓存的旧数据（stale-while-revalidate 思路）

缓存管理与版本更新

缓存不会自动更新，必须手动控制生命周期：

• 每次修改缓存策略或资源列表，需更改缓存名称（如 'cache-v2'），并在 install 阶段打开新缓存、预填内容
• 在 activate 事件中，调用 caches.keys().then(keys => ...) 删除旧缓存，避免冗余占用空间
• 可监听 message 事件，让页面主动触发 skipWaiting() 或 clients.claim()，加快新版生效

调试与容错要点

实际部署中常见问题需提前规避：

• 确保 sw.js 文件本身不被其他缓存策略干扰（如服务器禁止缓存 SW 脚本，设置 Cache-Control: no-cache）
• 避免在 fetch 事件中 await 未 catch 的 Promise，否则请求会挂起或报错；始终用 try/catch 包裹异步操作
• 本地测试时，可在 Chrome DevTools 的 Application → Service Workers 面板中勾选 “Update on reload” 并点击 “Skip waiting”，快速验证新版逻辑
• 对跨域请求（如字体、第三方 API），默认无法拦截；需服务端支持 CORS，且请求中显式设置 mode: 'cors'

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