Service Worker 缓存更新怎么配置或排查

Service Worker 缓存更新的关键，不是每次部署都让用户清空浏览器缓存，而是同时管理两件事：浏览器是否发现了新的 sw.js，以及新的 worker 是否把资源放进了新的缓存名。实际排查时，先看 worker 是 waiting 还是 activated，再看 Cache Storage 命中了哪个版本。

下面的示例固定使用 /sw.js，把缓存切换交给 CACHE_NAME。这样既能保留浏览器的更新机制，也能避免旧缓存继续供应已经部署下线的文件。

先分清 Service Worker 脚本更新与资源缓存更新

浏览器会检查注册范围内的 Service Worker 脚本；只有发现脚本内容发生字节级变化，才会安装一个新 worker。仅仅替换了 app.js，而 sw.js 仍然完全相同，并不能保证你的 install 再跑一次。因此生产环境不要把 sw-v3.js、sw-v4.js 当成日常发布入口，保持 /sw.js 稳定更容易维护。

资源版本则由应用自己管理。每次资源清单或构建产物改变，修改缓存名，例如从 site-static-v2 改为 site-static-v3。两者的职责可以这样记：

用版本化缓存让新资源进入 install

先让新 worker 写入独立缓存，再谈删除旧缓存。event.waitUntil() 会把安装阶段绑定到这个 Promise：预缓存失败时，新版本不会被当作成功安装。

const CACHE_NAME = "site-static-v3";
const PRECACHE_URLS = ["/", "/index.html", "/app.js", "/styles.css"];

self.addEventListener("install", (event) => {
  // 新版本单独建缓存；任一关键资源失败，就让安装失败而不是留下半套缓存。
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(PRECACHE_URLS))
  );
});

这里不要在旧缓存上直接覆盖同名文件。独立版本让回滚和定位更清楚：如果页面仍展示旧内容，可以在 Cache Storage 同时看到 site-static-v2 与 site-static-v3，先判断当前 worker 实际使用哪一个。

activate 清理旧缓存并选择接管时机

新 worker 安装成功后，旧 worker 可能仍在控制打开的页面。activate 适合清理旧缓存；但清理范围必须限制在自己应用的前缀内，不能把同一 origin 上其他应用的 Cache Storage 一并删除。

const ACTIVE_CACHES = [CACHE_NAME];

self.addEventListener("activate", (event) => {
  // 只删除 site-static- 前缀的旧缓存，避免误伤同源的其他应用。
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(
        keys
          .filter((key) => key.startsWith("site-static-") && !ACTIVE_CACHES.includes(key))
          .map((key) => caches.delete(key))
      )
    )
  );
});

如果页面需要版本一致性，默认等待旧页面退出通常更稳。self.skipWaiting() 会跳过 waiting，clients.claim() 会让已打开且处于作用域内的页面被新 worker 控制；二者都可能造成旧页面已经加载的 HTML 与新版本脚本混搭。购物车、编辑器、长连接后台这类页面，建议先给用户“发现新版本，点击刷新”的提示，再在用户确认后发送消息让 worker 接管。

fetch 策略避免旧缓存覆盖新部署

缓存版本切换后，fetch 仍然可能因为策略不合适而返回旧响应。导航页面通常更需要看到最新 HTML，可以优先网络、失败再回退缓存；带文件哈希的静态资源则适合缓存优先。

self.addEventListener("fetch", (event) => {
  const request = event.request;
  if (request.mode === "navigate") {
    // 导航先拿最新 HTML；离线时再回退到缓存首页。
    event.respondWith(
      fetch(request).catch(() => caches.match("/index.html"))
    );
    return;
  }

  event.respondWith(
    caches.match(request).then((cached) =>
      cached || fetch(request)
    )
  );
});

这个示例只展示策略边界。生产中还要处理非 GET 请求、跨域响应和网络请求失败；不要把接口数据无条件当成静态文件缓存。若构建系统已经给 app.8f3c.js 这类资源加哈希，缓存优先更安全，HTML 则负责引用新文件名。

用 DevTools 排查 waiting、缓存命中和作用域

“部署后没更新”可以按下面顺序缩小范围：

1. 在 navigator.serviceWorker.getRegistration() 中确认注册成功，检查 scope 是否覆盖当前页面。
2. 打开 Application 的 Service Workers，区分 installing、waiting 和 activated；若是 waiting，先判断是否故意等待旧页面关闭。
3. 在 Cache Storage 中确认新缓存名存在，且 index.html、脚本和样式没有缺失。
4. 在 Network 查看响应的来源与状态，结合 Request URL 判断是否由 Service Worker 返回，而不是把 HTTP 缓存误认成 Cache Storage。
5. 长期打开的单页应用可在合适时机调用 registration.update()；注册时的 updateViaCache 只影响 worker 脚本及其 imports，不影响 worker 自己发起的资源请求。

开发阶段可以使用 DevTools 的 Update on reload 辅助确认安装逻辑，但上线前仍要用真实的版本名、接管策略和刷新提示验证。不要把“强制刷新后正常”当成根因已经解决，它只说明绕过了当前 worker。

常见问题

只修改 index.html，为什么 Service Worker 没更新？

如果 sw.js 字节内容没有变化，浏览器可能不会重新执行它的 install。应更新缓存名或由构建流程生成明确的版本常量，并确保新 HTML 不再由旧缓存优先返回。

skipWaiting 和 clients.claim 是不是必须同时使用？

不是。前者改变 waiting 阶段，后者改变已打开页面的控制权。需要页面一致性时可以保留默认等待，或只在用户确认刷新后发送消息触发接管。

为什么删掉浏览器站点数据后又复现旧页面？

这通常说明服务器或部署层仍提供旧的 sw.js、作用域不对，或新版本的 fetch 策略又读回旧资源。应按 worker 状态、缓存名和 Network 来源三处逐项核对。