Service Worker 更新流程模拟器 - 等待/激活/刷新

这是 Service Worker 的核心设计机制。当浏览器检测到新的 SW 脚本并完成安装后，如果旧的 SW 仍在控制任何打开的页面，新 SW 就会进入 waiting 状态。这样可以防止同一应用同时运行两个不同版本的 SW，避免缓存不一致、请求拦截冲突等问题。新 SW 会一直等待，直到所有被旧 SW 控制的页面都关闭，或者开发者主动调用 skipWaiting() 方法。在模拟器中，你可以通过点击「检测更新」后观察新 SW 状态卡片的变化来直观理解这一机制。当所有被旧 SW 控制的页面关闭后，新 SW 会自动从 waiting 过渡到 activating 状态。等待机制是浏览器为数据一致性而做出的安全设计，理解这一点对于正确处理 SW 更新至关重要。

skipWaiting() 会让等待中的新 SW 立即激活，即使旧 SW 仍在控制页面。风险在于：两个版本的 SW 可能同时处理请求（旧页面用旧 SW，新页面用新 SW），导致缓存版本冲突。通常推荐在以下场景使用：① 配合 clients.claim() 一起使用，确保所有页面立即由新 SW 控制；② 在 SW 的 install 事件中预缓存关键资源时；③ 通过用户提示（如「新版本可用，点击刷新」）引导用户操作时。在模拟器中，你可以通过「Skip Waiting」按钮体验这一操作的效果，观察流程图从「安装等待」直接跳到「激活」阶段。skipWaiting() 并非总是最佳选择，对于涉及重要数据变更的应用，建议让用户主动刷新以确保一致性。

clients.claim() 让新激活的 SW 立即接管所有在它 scope 范围内的已打开页面（clients）。如果不调用此方法，新 SW 只会在后续新打开的页面或刷新后的页面中生效。默认情况下，SW 激活后不会自动接管已打开的页面，这是一种安全设计。调用 claim() 可以实现无缝切换，但需注意页面可能已经在旧 SW 的缓存策略下加载了部分资源。在模拟器中，你可以看到不调用 claim() 时页面仍然显示「受控 SW: v1 (旧)」，调用后则更新为新 SW 控制。最佳实践是在 activate 事件中调用 clients.claim()，并在调用前清理旧版本缓存，确保新 SW 从干净的状态开始接管。

可以通过监听 navigator.serviceWorker.registration 的 updatefound 事件来检测更新。当新的 SW 开始下载时，该事件触发。然后监听新 SW 的 statechange 事件，当状态变为 installed（即 waiting）时，说明有更新等待激活。示例代码：registration.addEventListener('updatefound', () => { const newSW = registration.installing; newSW.addEventListener('statechange', () => { if (newSW.state === 'installed' && navigator.serviceWorker.controller) { /* 有更新可用 */ } }); }); 浏览器默认在页面导航时自动检查 SW 更新，也可以通过 registration.update() 手动触发检测。在模拟器中，点击「检测更新」按钮就模拟了这一过程。检测更新的频率取决于浏览器实现，通常不会过于频繁以避免不必要的网络请求。

SW 生命周期分为 6 个阶段：① Parsed（解析）：浏览器解析 SW 脚本文件；② Installing（安装中）：触发 install 事件，通常用于预缓存关键资源；③ Installed/Waiting（已安装/等待）：安装成功，等待旧 SW 释放控制权；④ Activating（激活中）：触发 activate 事件，可清理旧版本缓存；⑤ Activated（已激活）：SW 已激活，可控制页面并拦截请求；⑥ Redundant（冗余）：SW 被新版本替换或安装失败，不再使用。在模拟器的流程图中，初始状态对应 parsed/installing，检测更新对应 installed，安装等待对应 waiting，激活对应 activating/activated，接管完成表示新 SW 完全控制了所有页面。理解每个阶段对于调试 SW 问题至关重要，可以通过监听 statechange 事件追踪 SW 的状态变化。

推荐策略：① 提示用户刷新：检测到更新后，在页面上显示提示条（如「新版本可用」），让用户主动点击刷新，这是最安全的做法；② 自动 skipWaiting + claim：适合对一致性要求不高的应用，可实现完全无缝的更新，但需确保新 SW 能兼容旧页面的请求；③ 延迟激活：等待用户自然关闭所有页面后自动更新，适合后台工具类应用；④ 使用 Registration.waiting.postMessage() 与 waiting 的 SW 通信，实现更精细的更新控制。在模拟器中，你可以依次尝试这些策略，感受不同方案的效果差异。建议根据应用的具体需求选择合适的更新策略，并在不同浏览器中进行充分测试。

「关闭所有页面」模拟了用户手动关闭所有被旧 SW 控制的页面的场景。当没有任何页面被旧 SW 控制时，新 SW 会自动从 waiting 状态过渡到 activating 状态，无需调用任何方法。这是一种自然的、被动的更新方式。而「Skip Waiting」是主动调用 skipWaiting() 方法，强制新 SW 立即激活，无论旧 SW 是否仍在控制页面。这种方式更主动，但需要配合 clients.claim() 来确保所有页面切换到新 SW。在实际开发中，关闭所有页面的方式虽然安全但用户等待时间不确定，Skip Waiting 配合提示横幅是更常见的做法。

当新 SW 激活后，旧版本的缓存可能仍然存在。如果不主动清理，会逐渐积累无用的缓存数据，浪费用户的存储空间。更严重的是，如果新旧版本的缓存键相同，旧版本的缓存可能覆盖新版本的内容，导致用户看到过时的资源。最佳实践是在 activate 事件中遍历所有缓存，删除不在当前版本缓存白名单中的缓存。典型代码：self.addEventListener('activate', event => { event.waitUntil(caches.keys().then(keys => Promise.all(keys.filter(key => key !== CURRENT_CACHE).map(key => caches.delete(key))))); }); 配合 skipWaiting() 确保 activate 事件能及时触发。

浏览器的 SW 更新检查机制因浏览器而异。Chrome 默认在每次页面导航（包括页面加载和刷新）时检查 SW 脚本是否有更新，检查方式是对比脚本的字节级内容。如果脚本内容没有任何变化，浏览器会跳过下载，不会触发 updatefound 事件。你也可以通过代码手动触发检查：navigator.serviceWorker.ready.then(reg => reg.update())。在模拟器中，「检测更新」按钮模拟了手动触发检查的行为。注意，浏览器不会实时监听 SW 脚本文件的变化，只在导航时检查，这是性能和资源的平衡设计。建议在部署新版本时确保 SW 脚本的文件名或内容确实发生了变化，否则浏览器可能无法检测到更新。

避免缓存不一致的核心策略是版本化管理。① 使用版本化缓存名：如 cache-v1、cache-v2，在 activate 事件中只保留当前版本的缓存，删除所有旧版本缓存；② 配合 skipWaiting() 和 clients.claim() 实现原子切换：确保所有页面在同一时刻切换到由新 SW 控制；③ 对关键 API 请求使用网络优先策略（network-first）：不缓存实时数据，避免新旧版本返回不同数据；④ 在新 SW 激活前预缓存关键资源：在 install 事件中使用 cache.addAll() 确保所有资源都已缓存后再激活。在模拟器中通过进阶实验可以更直观地理解这些策略的必要性。缓存管理是 SW 开发中最容易出错的环节，建议在项目初期就建立完善的缓存版本管理方案。