service worker 无专门离线缓存事件，依赖 install、fetch、activate 事件协同实现离线能力：install 预存静态资源，fetch 决定请求响应源，activate 清理旧缓存；online/offline 仅用于 ui 状态提示，不参与缓存逻辑。
离线缓存本身没有专门的“离线缓存事件”，它依赖 Service Worker 的生命周期事件（install、activate）和核心运行时事件（fetch）协同完成，而不是靠某个叫“offline cache event”的独立事件。
install 事件：预存静态资源，为离线打基础
这是缓存策略落地的第一步，不是响应用户请求，而是提前把关键静态文件（HTML、CSS、JS、图标等）存进 Cache Storage。
- 必须用
event.waitUntil()包裹异步操作，确保安装完成前缓存写入成功 - 路径要绝对且与页面实际请求完全一致（包括尾部斜杠、查询参数），否则
caches.match()找不到 - 推荐使用语义化缓存名，如
'static-v2.3.1'，方便后续版本管理
fetch 事件：真正决定“这次请求从哪来”，是离线能力的核心
每次页面发起 fetch 或导航请求，Service Worker 都会触发这个事件。你在这里做判断和响应，直接控制是否返回缓存、是否发起网络、是否更新缓存。
- 必须第一行调用
event.respondWith()，否则浏览器走默认流程，缓存逻辑彻底失效 - 按资源类型分流更可靠：用
event.request.destination（如'document'、'script'、'image'）比单纯看 URL 更准确 - Response body 只能读一次，缓存前务必
response.clone()，否则后续解析或存储会失败
activate 事件：清理旧缓存，保证环境干净
新 Service Worker 激活时执行，用来淘汰上一版缓存，避免磁盘占用和资源错乱。
- 配合
self.skipWaiting()（install 中）和self.clients.claim()（activate 中），让新版尽快接管所有页面 - 遍历
caches.keys()，只保留当前版本缓存名，其余全部caches.delete() - 不清理旧缓存，可能导致用户加载到过期 CSS 或 JS，出现样式错乱或功能异常
没有“离线事件”，但可以用 online/offline 监听网络状态变化
虽然这不是 Service Worker 的一部分，但可作为辅助手段：
-
window.addEventListener('online', ...)和window.addEventListener('offline', ...)能通知前端 UI 切换状态（比如显示“已离线”提示） - 它不能触发缓存行为，也不影响 fetch 拦截逻辑；真正的离线响应仍由 fetch 事件中的缓存匹配决定
- 注意：该事件有延迟，且某些浏览器在切换 Wi-Fi/移动网络时可能不触发，不可作为缓存逻辑的依据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
