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 时，把“请求进来 → 我想怎么答”这个逻辑理清楚，缓存自然就稳了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
