UD5工具箱
Service Worker
Service Worker 是一种运行在浏览器后台、独立于主线程的脚本，属于 Web Worker 的一种特殊类型。它能够拦截和处理网络请求，实现离线缓存、推送通知、后台同步等功能。在本模拟器中，Service Worker 以版本号区分新旧版本（v1 和 v2），用于演示多版本共存和更新切换的场景。SW 一旦注册成功，就会持续运行直到浏览器关闭或被手动注销。
SW 运行在独立的 Worker 线程中，无法直接访问 DOM，必须通过 postMessage 与主线程通信。它使用 Promise-based API，具有 install、activate、fetch 等核心事件。在模拟器中，你可以通过操作按钮间接体验这些事件的触发时机和效果。
skipWaiting()
skipWaiting() 是 Service Worker 全局作用域中的一个方法，调用后会让当前处于 waiting 状态的新 SW 立即进入 activating 状态，无需等待旧 SW 释放控制权。在模拟器中对应「Skip Waiting」操作按钮。需要注意的是，skipWaiting() 的作用范围仅限于当前 SW 的 scope，不会影响其他 scope 的 SW。
该方法通常在 SW 的 install 事件中调用，或者配合用户提示（如「新版本可用」横幅）使用。调用 skipWaiting() 后，新 SW 会立即触发 activate 事件，此时可以在 activate 事件中清理旧版本缓存。但需要注意，skipWaiting() 不会自动让新 SW 接管已打开的页面，通常需要配合 clients.claim() 使用。
clients.claim()
clients.claim() 让新激活的 Service Worker 立即接管所有在其 scope 范围内已打开的页面（clients）。默认情况下，新 SW 激活后不会自动接管已打开的页面——这些页面仍然由旧 SW 控制，直到页面被刷新或重新打开。在模拟器中对应「Clients Claim」操作按钮。该方法在 SW 激活后调用效果最佳。
claim() 的返回值是一个 Promise，resolve 时表示接管操作已完成。该方法常与 skipWaiting() 配合使用以实现无缝更新：先 skipWaiting() 激活新 SW，再 claim() 接管所有页面。调用后，所有已打开页面会立即切换到由新 SW 处理请求和响应。需要注意的是，页面在切换过程中可能已经在旧 SW 的缓存策略下加载了部分资源，这可能导致短暂的不一致。
updatefound 事件
当浏览器检测到新的 Service Worker 脚本（通过比对脚本内容的字节级差异）并开始下载时，会触发 registration 的 updatefound 事件。在模拟器中，点击「检测更新」按钮后触发的就是这个事件。监听此事件可以获取到新 SW 的 installation 对象，进而监听其 statechange 事件来追踪安装进度。
浏览器通常在页面导航时自动检查 SW 更新，也可以通过调用 registration.update() 手动触发。updatefound 事件只会在 SW 脚本内容确实发生变化时触发，如果脚本没有任何改动，浏览器会跳过下载。这一机制确保了更新检测的高效性，避免不必要的网络请求。在实际开发中，监听 updatefound 事件可以实现「新版本可用」提示横幅的功能。
SW 生命周期
Service Worker 的完整生命周期包含六个阶段：Parsed（解析脚本）、Installing（安装中，触发 install 事件）、Installed/Waiting（已安装/等待中，等待旧 SW 释放）、Activating（激活中，触发 activate 事件）、Activated（已激活，可控制页面）、Redundant（冗余/被替换）。
在模拟器的流程图中，主要展示了从初始状态到接管完成的五个关键节点。每个阶段都有明确的触发条件和状态转换逻辑。理解每个阶段的触发条件和行为对于调试 SW 相关问题至关重要。例如，如果 SW 一直卡在 waiting 状态，可能是有页面被旧 SW 控制；如果 SW 进入 redundant 状态，说明有更新版本的 SW 已经安装并替换了当前版本。
waiting 状态
当新 SW 安装完成但旧 SW 仍在控制页面时，新 SW 进入 waiting 状态。这是 SW 更新机制中最关键也最容易让开发者困惑的阶段。浏览器强制执行 waiting 状态的目的是防止同一应用同时运行两个版本的 SW，避免缓存策略冲突和数据不一致。在模拟器中，点击检测更新后新 SW 会显示为「等待中」。
可以通过三种方式结束 waiting 状态：关闭所有旧 SW 控制的页面（自然激活）、调用 skipWaiting()（强制激活）、或在 SW 的 install 事件中自动调用 skipWaiting()（自动激活）。waiting 状态的存在是浏览器对开发者的一种保护机制，确保更新过程的安全性和一致性。在模拟器中，你可以通过不同的操作组合来探索这三种方式的区别和效果。
无缝更新
无缝更新是指用户在无感知的情况下完成 SW 版本切换的过程。实现无缝更新的典型策略是：在新 SW 的 install 事件中调用 skipWaiting()，在 activate 事件中调用 clients.claim()。这样可以确保新 SW 安装后立即激活并接管所有已打开页面，用户不会看到任何中断或闪烁。
在模拟器中，依次执行检测更新、Skip Waiting、Clients Claim 三个操作即可模拟无缝更新流程。生产环境中，还需要考虑缓存版本管理（如使用版本化缓存名）以避免新旧版本资源冲突。无缝更新并非适用于所有场景——对于涉及重要数据变更的应用，可能需要提示用户主动刷新以确保看到最新内容。
缓存冲突
缓存冲突是指两个不同版本的 Service Worker 同时操作缓存时导致的数据不一致问题。例如，旧 SW 可能缓存了 API 响应 v1，而新 SW 缓存了 API 响应 v2。如果用户在新旧页面之间切换，可能会看到不一致的数据。这就是浏览器强制执行 waiting 状态的原因之一。
在模拟器的进阶实验中，你可以通过在不同阶段切换页面来理解潜在的缓存冲突风险。生产环境推荐使用版本化的缓存键（如 cache-v1、cache-v2）并在 activate 事件中清理旧版本缓存，从根本上避免缓存冲突的发生。缓存冲突是 PWA 开发中最常见的 Bug 来源之一，理解其成因有助于编写更健壮的 SW 代码。
SW Scope
Service Worker 的 scope 定义了 SW 能够控制哪些页面。默认情况下，SW 的 scope 是其脚本文件所在的目录。例如，注册在 /sw.js 的 SW 的 scope 是 /，可以控制整个域名下的页面。在模拟器中，所有页面（index.html、about.html、contact.html）都在同一个 scope 下，因此可以被同一个 SW 控制。
理解 scope 概念对于正确配置 SW 的控制范围非常重要——如果 SW 脚本放在子目录中，它可能无法控制父目录的页面。可以通过 registration.scope 属性查看当前 SW 的实际 scope，也可以在注册时通过 scope 选项指定自定义 scope（前提是自定义 scope 必须在脚本文件所在的目录或其子目录中）。scope 的正确配置是 SW 正常工作的基础。
事件日志与调试
在模拟器底部的事件日志区域，每一步操作都会记录带有时间戳的事件信息。这些事件对应了真实 SW 调试中的关键日志点。在实际开发中，开发者可以通过 Chrome DevTools 的 Application 面板查看 SW 的注册状态、更新状态和缓存内容。Firefox 也提供了类似的 SW 调试工具。事件日志是理解 SW 内部行为的重要工具，建议开发者在使用模拟器时养成观察日志的习惯，这将帮助你在实际项目中更高效地调试 SW 相关问题。
实际开发中的 SW 调试技巧包括：使用 console.log 在 SW 中输出调试信息（在 DevTools 的 Service Worker 面板中查看）、使用 Cache Storage 面板检查缓存内容、使用 Network 面板查看 SW 拦截的请求和响应。模拟器的事件日志系统虽然简化了这些信息，但其核心逻辑与真实调试是一致的——通过观察事件流来理解 SW 的行为模式。