17370845950

Service Worker 是浏览器后台脚本，负责拦截请求、管理缓存（通过 Cache API）、实现离线访问等；其核心是按资源特性动态选择缓存策略，如 Cache-First、Network-First、Stale-While-Revalidate 等，并需注意版本管理、预缓存、旧缓存清理及跨域限制。

Service Worker 是一种运行在浏览器后台的脚本，独立于网页主线程，能拦截网络请求、管理缓存、实现离线访问和推送通知等功能。它本身不是缓存，而是控制缓存的“管理员”——真正存数据的是 Cache API（如 cache.put()、cache.match()），而 Service Worker 决定“什么时机、用什么逻辑去读/写/更新这些缓存”。

常见缓存策略（由 Service Worker 实现）

策略本质是：收到请求后，Service Worker 怎么决策——是走网络？读缓存？还是先缓存再更新？

• Cache-First（缓存优先）：先查 Cache，命中就直接返回；未命中再发网络请求，并把响应存入缓存再返回。适合静态资源（如 logo、CSS、JS），减少重复下载。但缺点是更新不及时，需配合版本更新或 cache busting（如加 hash 后缀）。
• Network-First（网络优先）：先发网络请求；成功则返回响应并更新缓存；失败时再 fallback 到缓存。适合内容常变但又不能完全离线的场景（如新闻列表页）。注意要处理好“网络失败+缓存也不存在”的兜底逻辑（比如显示默认页）。
• Stale-While-Revalidate（过期但仍可用 + 异步更新）：立即返回缓存内容（即使过期），同时后台悄悄发网络请求，拿到新响应后更新缓存。用户感知快，又能保证后续请求拿到最新版。适合博客文章、用户资料等对实时性要求不高但需最终一致的资源。
• Cache-Only / Network-Only：极简策略。前者强制只读缓存（适合纯离线场景）；后者强制只走网络（适合敏感操作，如登录、支付接口，避免缓存污染）。

策略不是固定写死的，而是按 URL 或资源类型动态选择

同一个 Service Worker 可以对不同请求应用不同策略。例如：

• /static/ 开头的资源 → Cache-First
• /api/user → Stale-While-Revalidate
• /api/order/submit → Network-Only

这靠在 fetch 事件监听器里用 event.request.url 或 event.request.destination 做条件判断实现。

关键注意事项

Service Worker 缓存不是自动生效的，需要主动注册、激活、并正确编写 fetch 逻辑。常见坑包括：

• 缓存名称没做版本管理，导致旧缓存一直残留（建议用 CACHE_NAME = 'my-app-v2' 这类带版本号的名字）
• install 阶段没 waitUntil() 确保预缓存完成，导致 activate 失败
• 没在 activate 阶段清理旧缓存，造成磁盘浪费
• 跨域资源（如 CDN 图片、第三方 API）默认无法缓存，除非响应头含 Access-Control-Allow-Origin

基本上就这些。策略选型没有绝对好坏，核心是看资源特性：变不变、重不重要、能不能离线、用户是否在意延迟。写 Service Worker 时，把“请求进来 → 我想怎么答”这个逻辑理清楚，缓存自然就稳了。