Service Worker 不能直接实现灰度发布或版本回滚，需与构建、CDN/网关、运行时决策协同：构建生成带版本标识的 SW 脚本；CDN/网关按用户特征分流 HTML 与资源路径；SW 在 fetch 中基于版本标识构造缓存键；回滚通过切换入口指向历史版本资源链路实现。
Service Worker 本身不能直接实现灰度发布或版本回滚，它只是一个事件驱动的客户端代理脚本，不具备按用户条件激活、动态加载多版本逻辑的能力。真正可行的方案，是把它作为缓存执行层，配合构建、CDN/网关、运行时决策三者协同工作。
构建层：生成带版本标识的 Service Worker 脚本
每次构建新版本时，生成唯一内容哈希或语义化版本号的 sw.js?v=1.2.3，并确保 HTML 中注册语句也同步更新：
- 避免浏览器强缓存旧版 SW：不复用同一 URL，改用带查询参数或哈希路径（如
/sw-abc123.js） - HTML 注入需动态化：服务端或构建时根据当前灰度策略注入对应版本的
navigator.serviceWorker.register() - SW 文件本身不包含业务逻辑分支，只负责按运行时传入的版本上下文做缓存读写
CDN 或网关层：分流 HTML 入口与资源路径
用户访问首页时，不是由前端 JS 决定走哪个版本，而是由边缘节点根据请求特征返回不同 HTML 片段：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 依据 Cookie（如
gray-version=v2）、Header（X-Gray-Flag: true）或 IP 段识别灰度身份 - 返回的 HTML 中已预置对应版本的 SW 注册代码和静态资源 base URL（如
/static/v2/） - 这样从页面加载第一刻起，整个资源链路（HTML → SW → JS/CSS/图片）就锁定在指定版本通道内
运行时缓存键设计：让同一 URL 可区分版本缓存
在 Service Worker 的 fetch 事件中，不能直接用原始 URL 做 cache key，否则 v1 和 v2 的 /app.js 会互相覆盖：
立即学习“前端免费学习笔记（深入）”；
- 从 document.cookie 或 request.headers 读取当前生效的版本标识（注意：install 阶段不可读，只能在 fetch 中）
- 构造带版本前缀或查询参数的缓存键，例如：
https://example.com/app.js?v=v2 - 使用
caches.open('cache-v2')或统一缓存名 + 键名区分，避免跨版本污染 - 示例逻辑：const version = getCookieVersion(); const cacheKey = new URL(req.url).origin + new URL(req.url).pathname + '?v=' + version;
回滚机制：依赖缓存保留 + 快速切换入口
所谓“多级回滚”，本质是快速切回历史版本的完整资源链路，而非在单个 SW 内做状态倒退：
- 所有历史版本的 HTML、SW 脚本、静态资源均保留在 CDN，路径按版本隔离（如
/v1.1.0/index.html） - 一旦触发回滚，只需修改网关规则或 DNS 解析，将用户流量导向旧版 HTML 入口
- 旧版 HTML 自动注册对应旧版 SW，并加载旧版资源，整个过程对用户无感，也不依赖客户端清除缓存
- 可配合 Cache API 在 SW 中主动清理非当前版本的缓存，减少本地冗余
