企业级 service worker 更新策略核心是可控、可测、可回滚：构建时注入 git hash 或语义化版本作为 cache_name 基础；分阶段接管——waiting 期提示用户、激活后刷新；多环境差异化配置；通过 puppeteer 自动化测试+灰度验证+异常兜底保障可靠性。
企业级项目中落地 Service Worker 更新策略，核心不是“能不能注册”，而是“更新是否可控、可测、可回滚”。关键在于把 SW 的生命周期管理纳入 CI/CD 流程，并建立面向真实用户行为的验证机制。
版本标识与构建联动
避免硬编码版本号或靠人工维护 meta 标签。应在构建阶段注入唯一、可追溯的标识：
- 使用 Git commit hash 或语义化版本 + 构建时间戳（如
v2.4.1-20261009-1422）作为CACHE_NAME和 sw.js 内容哈希依据 - Vite 项目可在
vite.config.ts中通过define注入环境变量：__SW_VERSION__: JSON.stringify(process.env.BUILD_VERSION) - 在
sw.js中用该变量生成缓存名：const CACHE_NAME = `app-${__SW_VERSION__}`，确保每次构建生成全新缓存空间
更新触发与用户无感接管
不依赖用户手动刷新，也不在 waiting 状态就强制 reload。应分阶段控制更新节奏：
macOS Automator Services
下载
部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...
- 新 SW 安装后进入
waiting状态，此时旧 SW 仍在控制页面 —— 这是安全窗口期 - 监听
controllerchange事件，在新 SW 激活后才提示用户“新版已就绪”，并提供“立即启用”按钮（调用skipWaiting()+location.reload()） - 对后台长期运行的管理页（如监控大屏），可设置
self.skipWaiting()在 install 阶段直接跳过 waiting，但需配合灰度发布机制
多环境差异化策略
开发、测试、预发、生产环境应使用不同更新逻辑，防止误操作影响线上：
- 开发环境：禁用 SW 注册，或注册时加
?dev=1参数，使 sw.js 返回 404，避免干扰热更新 - 测试/预发环境：启用 SW，但缓存策略设为
Network First，且所有 fetch 请求代理到 mock 接口，便于验证离线行为 - 生产环境：启用
Stale-While-Revalidate缓存策略，关键静态资源走 Cache First，API 请求走 Network First + 后台静默更新
可验证的端到端测试方案
不能只测“注册成功”，要覆盖真实场景下的更新链路：
- 自动化测试：用 Puppeteer 启动 Chromium，模拟用户首次访问 → 关闭浏览器 → 修改服务端 version.json → 重启浏览器 → 验证是否触发 waiting → 手动激活后 DOM 是否加载新版资源
- 灰度验证：通过 URL 参数（如
?sw=beta）或 Cookie 控制小比例用户加载新版 sw.js，埋点统计install、activate、controllerchange事件上报率 - 异常兜底：在
fetch事件中捕获未命中缓存且网络失败的请求，记录错误类型和 URL 到localStorage，上线后收集分析高频失败资源，优化缓存清单
