ServiceWorker安装激活流程详解

本文深入剖析了 Service Worker 的 install 与 activate 两大核心生命周期阶段，揭示其背后严格的状态流转机制（installing → installed → activating → activated），强调 install 阶段专注资源预缓存且必须通过 waitUntil 保证原子性，而 activate 阶段才是唯一安全执行缓存清理与版本迁移的时机——二者绝不可混淆或互换；同时指出状态推进高度依赖页面生命周期、skipWaiting() 调用及多标签协同策略，直击实际开发中缓存混乱、白屏、版本冲突等高频痛点，为构建稳定可靠的离线 Web 应用提供关键底层认知。

Service Worker 的 `install` 和 `activate` 不是简单的先后触发事件，而是对应两个明确、不可跳过的状态阶段：**installing → installed → activating → activated**。理解它们之间的流转逻辑，关键在于搞清“何时发生”、“谁在控制”以及“为什么不能互换”。

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，两者缓存策略若不兼容，就可能出现资源加载混乱。所以版本管理和缓存命名规范不是可选项，而是必须项。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《ServiceWorker安装激活流程详解》文章吧，也可关注golang学习网公众号了解相关技术文章。