service worker 更新流程验证需依次确认四环节：一、更新触发机制（检查sw.js缓存策略与内容变更是否引发waiting状态）；二、安装激活行为（通过日志与skip waiting验证install/activate执行及缓存清理）；三、缓存资源切换（核对cache storage中多版本缓存内容与fetch命中情况）；四、用户场景感知（测试controllerchange事件、自动刷新及跨标签页更新链路）。

测试 Service Worker 更新流程是否符合预期，关键在于验证“旧版本能否被正确卸载、新版本能否安装激活、缓存资源能否按需切换、用户是否获得最新内容”这四个环节。整个过程不依赖自动部署，而是通过可控的本地操作和浏览器工具逐层验证。

一、确认更新触发机制是否生效

Service Worker 的更新不是实时推送，而是由浏览器在页面加载时对比当前注册的 SW 脚本与服务器返回的 SW 文件内容是否一致来决定是否拉取新版本。要验证触发逻辑：

• 确保 sw.js 文件本身没有被强缓存（例如响应头中设置 Cache-Control: no-cache 或 max-age=0），否则浏览器可能根本不会重新请求它；
• 修改 sw.js 中任意一行代码（比如加个 console.log），保存后刷新页面；
• 打开 Chrome/Edge 的 Application → Service Workers 面板，观察是否出现“Waiting”状态的新 SW 条目；
• 若未出现，检查 Network 面板中 sw.js 请求是否返回 304（说明缓存未失效）或 404（路径错误）。

二、验证安装与激活行为是否正确

安装（install）和激活（activate）是两个独立阶段，必须分别确认其执行结果：

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 在 sw.js 的 install 事件中添加日志，如 console.log('[SW] Installing v2')，刷新后查看 Console 是否输出；
• 在 activate 事件中加入清理逻辑（如删除旧缓存）并加日志，确认旧缓存名（如 my-app-v1）是否被移除、新缓存（如 my-app-v2）是否创建成功；
• 勾选 Application → Service Workers 面板中的 Skip waiting，可跳过 waiting 状态，让新 SW 立即激活；
• 点击 Unregister 后刷新，再看是否重新注册并进入 install → waiting → activate 流程。

三、检查缓存资源是否随版本切换

版本化缓存名是实现“新旧分离”的核心。测试重点是：v1 缓存的资源是否还在、v2 缓存是否包含新文件、fetch 是否命中对应版本：

• 打开 Application → Cache Storage，展开对应缓存名（如 my-app-v1 和 my-app-v2），核对各自缓存的 URL 列表是否与代码中 CACHE_ASSETS 一致；
• 在 Network 面板勾选 Disable cache，然后断网刷新页面，观察关键资源（如 index.html、app.js）是否从 v2 缓存中返回（Status 显示 from ServiceWorker）；
• 手动删除 v1 缓存，再刷新，确认页面仍能正常加载——说明 fetch 逻辑没硬编码旧缓存名。

四、模拟真实用户场景验证更新感知

用户不会主动点“更新”，所以要测试静默更新后的表现：

• 保持一个页面长期打开（不刷新），部署新版本 sw.js 后再次访问同一地址，观察 Application 面板是否出现“controllerchange”事件；
• 在主页面 JS 中监听该事件：navigator.serviceWorker.addEventListener('controllerchange', () => location.reload())，确认页面是否自动刷新；
• 用两个标签页测试：A 页面保持打开（控制权在旧 SW），B 页面刷新后使用新 SW，再回到 A 页面调用 navigator.serviceWorker.getRegistration().then(r => r?.update())，观察是否触发更新链路。