Service Worker的install和activate事件分别对应installing→installed和activating→activated状态阶段，install阶段缓存资源并需waitUntil确保完成，activate阶段清理旧缓存且不可在install中执行，状态流转受页面生命周期和skipWaiting()控制。
install 阶段对应 installing → installed 状态
脚本注册成功并解析完成后，浏览器自动进入 installing 状态，此时触发 `install` 事件。这个阶段的核心任务是准备资源——尤其是缓存静态文件。
- 必须用
event.waitUntil()包裹异步操作（如caches.open().then(cache.addAll([...]))），否则安装可能被中断 - 如果缓存失败或脚本抛错，状态直接转为 redundant，不会继续流转
- 安装成功后进入 installed 状态，也叫“等待态”——它不会立刻激活，要等旧版 SW 释放控制权
- 同一时刻，一个作用域下最多只有一个
registration.installing或registration.waiting实例，但可以有多个 tab 正在使用旧版 active SW
activate 阶段对应 activating → activated 状态
activating 状态只在 Service Worker 即将接管页面时触发 `activate` 事件。这是唯一安全执行清理和迁移的时机。
- 不能在 `install` 中删旧缓存——此时新旧 SW 可能共存，误删会导致已有页面加载失败甚至白屏
- 推荐用版本前缀匹配清理：
caches.keys().then(keys => Promise.all(keys.map(key => key.startsWith('my-cache-') && key !== 'my-cache-v2' ? caches.delete(key) : null))) - 想跳过等待、立即激活，可在 `install` 中调用
self.skipWaiting()，或在页面中向 waiting 中的 SW 发送{type: 'SKIP_WAITING'}消息 - 只有进入 activated 后，SW 才真正开始拦截 fetch、处理 push，并控制新打开或刷新的页面
状态流转受页面生命周期影响
即使新 SW 已 `installed`，它也不会自动 `activating`，除非满足以下任一条件：
- 所有使用旧版 SW 的页面已关闭（包括 background tabs）
- 当前页面主动刷新（新导航会尝试用新版）
- 代码显式调用
skipWaiting()并完成等待态切换 - 用户手动清除站点数据或禁用相关存储，导致旧 SW 失效
多个 tab 共存时最易出问题：一个 tab 还在用 v1，另一个 tab 加载了 v2，两者缓存策略若不兼容，就可能出现资源加载混乱。所以版本管理和缓存命名规范不是可选项，而是必须项。
