Service Worker 更新后旧缓存为什么还在使用

Service Worker 文件已经部署，页面却还显示旧的 JavaScript 或 CSS，最常见的原因不是“缓存没有刷新”这么简单：新 worker 可能停在 waiting，当前页面仍由旧的 controller 控制；即使新 worker 已激活，fetch 也可能继续读取旧的 Cache Storage。排查时要把 worker 生命周期、页面控制权和缓存名称分开看。

先看清：旧缓存可能来自三个不同位置

浏览器检测到 /sw.js 内容发生字节变化后，会安装一个新的 worker。已有页面仍被旧 worker 控制时，新 worker 会进入 waiting；这时 DevTools 里可能已经出现新脚本，但页面请求依旧经过旧 worker。只有旧 worker 不再控制客户端，新 worker 才会自然激活。

第二种情况是页面已经切换到新 worker，但新代码仍写着 caches.open('app-v1')，于是它继续命中旧资源。第三种情况是 worker 激活了，当前文档却是在切换前加载的，页面的 navigator.serviceWorker.controller 仍然是旧实例。下面的静态关系图把这三层边界放在一起，便于定位。

用版本化缓存避免新 worker 复用旧资源

每次静态资源集合发生变化，就改动缓存名，例如从 app-static-v1 换到 app-static-v2。安装阶段只准备新缓存，激活阶段再删除带有本应用前缀、但不在白名单中的缓存。这样即使旧页面短时间仍在运行，也不会和新资源混在同一个缓存槽里。

const CACHE_NAME = 'portal-static-v2';
const ASSETS = ['/', '/index.html', '/app.js', '/styles.css'];

self.addEventListener('install', (event) => {
  // 新版本只负责准备自己的资源，不删除旧缓存。
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(ASSETS))
  );
});

self.addEventListener('activate', (event) => {
  // 只清理 portal- 前缀，避免误删同源下其他应用的缓存。
  event.waitUntil(
    caches.keys().then((keys) => Promise.all(
      keys
        .filter((key) => key.startsWith('portal-') && key !== CACHE_NAME)
        .map((key) => caches.delete(key))
    ))
  );
});

self.addEventListener('fetch', (event) => {
  // 这里只演示静态资源优先读当前版本缓存，其他请求交给网络。
  const request = event.request;
  if (request.method !== 'GET') return;
  event.respondWith(
    caches.match(request).then((cached) => cached || fetch(request))
  );
});

这段代码的关键不在于把数字写成 v2，而在于 install、activate 和 fetch 使用同一个当前缓存名。若只改了 install 的版本号，fetch 仍指向旧缓存，部署后的页面当然还会看到旧文件。

什么时候使用 skipWaiting 和 clients.claim

self.skipWaiting() 只会让新 worker 尽快从 waiting 进入 active，并不会自动替换已经打开文档中的代码。clients.claim() 则是在 activate 后让作用域内的客户端采用当前 worker；页面还要监听 controllerchange，决定是提示用户刷新，还是在确认资源兼容后自动刷新。

self.addEventListener('install', (event) => {
  // 只有新旧资源可以同时工作时，才跳过 waiting。
  self.skipWaiting();
});

self.addEventListener('activate', (event) => {
  // 让已打开且处于作用域内的页面获得新的控制器。
  event.waitUntil(clients.claim());
});

navigator.serviceWorker.addEventListener('controllerchange', () => {
  // 避免一次更新触发多次刷新；也可以改成显示“发现新版本”按钮。
  if (!window.__swReloaded) {
    window.__swReloaded = true;
    window.location.reload();
  }
});

如果新 worker 改变了接口格式、IndexedDB 结构或页面依赖的资源组合，立即接管会让旧页面和新 worker 混用，风险反而更高。此时可以不调用 skipWaiting()，改为在页面发现 registration.waiting 后给用户一个更新按钮；长时间不刷新页面的应用还可以在合适时机调用 registration.update()。

按四项检查清单定位“更新了但仍是旧文件”

开发时可以在浏览器的 Application 面板查看 registration 的 waiting、active 和 Cache Storage；这只是定位手段，不应把清空站点数据当成生产修复。部署时还要保持 worker 脚本 URL 稳定，通过脚本内容变化触发更新，而不是不断换成 sw-v2.js 之类的新注册地址。

常见问题

刷新一次为什么还是旧页面？

刷新期间旧页面可能仍被旧 worker 控制，更新后的 worker 仍在 waiting。确认 waiting 已转为 active，并检查页面的 controller 是否发生变化。

改了缓存名还需要 skipWaiting 吗？

不一定。缓存名解决资源隔离，skipWaiting 解决接管时机；前者不能替代后者，后者也不能修复 fetch 仍使用旧缓存名的问题。

clients.claim 会不会刷新页面？

它本身只改变控制器并触发 controllerchange，不负责刷新。是否刷新由页面代码决定，旧页面与新 worker 不兼容时应先提示用户。