Service Worker 通过 install、fetch、activate 三阶段实现缓存：install 预缓存静态资源并带版本号；fetch 动态缓存响应并注意克隆分流；activate 清理旧缓存；调试需借助 DevTools 的 Cache Storage 和 Offline 模拟。
Service Worker 通过拦截网络请求、主动存取 Cache Storage 来实现资源缓存，核心是 install 和 fetch 两个生命周期事件的配合。
安装阶段预缓存静态资源
在 install 事件中，打开一个命名缓存（如 'v1'），用 caches.open() 获取缓存对象，再调用 cache.addAll() 批量添加关键静态资源（HTML、CSS、JS、图标等）。这些资源会在 Service Worker 激活前就存入缓存，确保离线可访问。
- 推荐只缓存版本明确、不常变更的资源，避免缓存污染
-
event.waitUntil()必须包裹异步操作，防止安装失败 - 缓存名建议带版本号（如
'static-v2'），便于后续更新时清理旧缓存
运行时动态缓存新请求
在 fetch 事件中，先尝试从缓存匹配；未命中则发起网络请求，并将响应克隆后存入缓存（注意：响应流只能读一次，需用 response.clone() 分流）。
- 对 HTML 请求建议优先走网络（防止缓存过期首页），其他资源可“缓存优先”策略
- 可按 URL 规则区分缓存策略，例如 API 接口设短时效，图片设长时效
- 使用
caches.match(request)查找缓存，返回 Promise，需用await或.then()
激活阶段清理旧缓存
在 activate 事件中，遍历 caches.keys()，删除非当前版本的缓存。这一步确保旧资源不会残留干扰新逻辑。
立即学习“Java免费学习笔记（深入）”；
- 必须调用
event.waitUntil()等待清理完成 - 通常配合版本号判断，比如只保留以
'v1'开头的缓存名 - 激活成功后，旧 Service Worker 彻底被替换，新缓存策略立即生效
调试与验证缓存行为
在 Chrome DevTools 的 Application → Cache Storage 面板可查看已缓存的内容；Network 面板勾选 “Disable cache” 并启用 “Offline” 可模拟离线场景。还可监听 fetch 事件中的 event.request.destination 过滤资源类型（如 'script'、'image'）做精细化控制。
- 缓存的 Response 对象默认不可修改，如需添加 header，需新建
new Response(body, options) -
跨域资源需服务端设置
Access-Control-Allow-Origin，否则无法缓存 - 导航请求（
destination: 'document'）返回的 HTML 响应默认不支持缓存，需服务端加Cache-Control头
基本上就这些。缓存逻辑不复杂但容易忽略细节，关键是理清 install / fetch / activate 各自职责，再结合实际资源类型设计策略。
