Service Worker 更新怎样控制接管时机

Service Worker 更新时，新文件通常会先进入 waiting，等旧页面不再使用旧 Worker 后才激活。如果产品希望缩短“发布到生效”的时间，可以在新 Worker 的 install 事件里调用 self.skipWaiting()，再在 activate 事件里调用 self.clients.claim()。前者改变激活时机，后者改变已打开页面的控制关系，两者不是同一个开关。

官方资料：https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

先分清 waiting、active 与 controller

Service Worker 更新可以拆成三个观察点：新脚本下载并安装完成后可能处于 waiting；跳过等待并完成激活后才是 active；某个页面是否真的由它处理请求，还要看页面上的 navigator.serviceWorker.controller。因此，看到新文件下载成功，并不能说明当前页面已经切换。

默认等待是为了避免同一个站点的旧页面和新 Worker 同时处理请求时出现不一致。MDN 对生命周期的说明也把“安装、激活、控制页面”分成不同阶段：新 Worker 可以更早激活，但现有文档是否被接管仍是另一个问题。

用 skipWaiting 提前激活新 Worker

skipWaiting() 只应在 Service Worker 全局作用域中调用，常见位置是 install 监听器。它返回一个 Promise，但示例中可以直接发起调用；真正需要等待的安装资源仍应放进 event.waitUntil()，不能因为跳过 waiting 就省略安装失败处理。

// service-worker.js
self.addEventListener('install', (event) => {
  // 只有安装资源准备完成后，才允许新版本进入下一阶段。
  event.waitUntil(
    caches.open('app-v4').then((cache) => {
      // 这里的资源列表必须与当前页面脚本兼容，避免半套缓存接管页面。
      return cache.addAll(['/index.html', '/app.js', '/styles.css']);
    }),
  );

  // 请求跳过 waiting；它改变的是 Worker 激活时机，不是页面刷新时机。
  self.skipWaiting();
});

如果新缓存还没有准备好就强行接管，页面可能拿到旧 HTML、新脚本或缺失资源。实际项目应先保证安装阶段的资源集合完整，再决定是否接受“立即激活”这一策略。

用 clientsClaim 接管现有页面

新 Worker 成为 active 后，新打开的页面通常会自然落入它的控制范围；已经打开的页面则未必立刻改变 controller。clients.claim() 放在 activate 中，可以让当前 scope 内符合条件的页面立即被新 Worker 接管，并触发页面侧的 controllerchange 事件。

// service-worker.js
self.addEventListener('activate', (event) => {
  event.waitUntil(
    // 让同一 scope 内已打开的页面获得当前 active Worker 的控制权。
    self.clients.claim(),
  );
});

这一步要谨慎：页面可能已经加载了旧版本的内联代码，而后续 fetch 却交给新 Worker。若两版缓存键、响应格式或消息协议不兼容，接管越快，混用窗口反而越集中。

页面侧可以监听控制器变化，但不要在每次事件里无条件刷新，否则多标签页更新时容易形成刷新循环：

// app.js
navigator.serviceWorker.addEventListener('controllerchange', () => {
  // 用一次性标记避免同一页面在多个 controllerchange 中重复刷新。
  if (sessionStorage.getItem('sw-reloaded') === '1') {
    return;
  }
  sessionStorage.setItem('sw-reloaded', '1');

  // 只有确认新旧资源协议兼容时，才采用自动刷新策略。
  window.location.reload();
});

用版本协商控制接管风险

可以把策略分成两档。资源格式和页面协议完全兼容时，skipWaiting + clients.claim 适合缩短生效延迟；如果升级包含数据库结构、消息字段或缓存响应格式变化，则让旧页面自然退出更稳妥，或者只在用户点击“立即更新”后发送消息让 waiting Worker 执行 skipWaiting()。

指标驱动的判断比“感觉更新快了”可靠。先记录一次基线，例如从发布到大多数活跃页面切换需要 20 分钟、旧缓存命中率为 8%；再观察改成主动接管后更新时间是否降到 1 分钟以内，以及 controllerchange 后的刷新次数、错误率和回滚次数是否上升。主动接管只应该改善生效延迟，不能以错误率增加为代价。

常见问题

调用 skipWaiting 后为什么当前页面还是旧内容？

因为它主要推动 waiting Worker 进入 active，当前页面是否切换还取决于 controller。需要在兼容性允许时配合 clients.claim()，或者等待页面重新加载。

clients.claim 会不会自动刷新页面？

不会。它会改变控制关系并可能触发 controllerchange，是否刷新由页面代码决定。自动刷新前要用一次性标记和版本兼容条件防止循环。

什么时候不适合立即接管？

当新旧页面使用不同缓存响应格式、消息协议或持久化数据结构时，不宜无条件立即接管。可以保留 waiting 状态，展示更新提示，让用户在安全的页面边界主动刷新。