service worker 本身不提供灰度自动回滚能力，需构建层生成带哈希与版本号的资源及sw脚本、cdn/网关按灰度策略分发对应html入口、运行时基于版本化缓存与失败计数实现自动降级，并通过广播通知、日志上报和指标监控闭环验证。
Service Worker 本身不提供“灰度自动回滚”能力，它只是一个被动注册、全局生效的脚本。真正实现该目标，需把 Service Worker 当作执行终端，由构建层、CDN/网关层和运行时逻辑三方协同驱动——核心是让不同灰度通道用户加载不同版本的资源快照，并在检测异常时自动切换回上一稳定版本。
构建层：生成带语义化版本的静态资源与 SW 脚本
每次构建必须产出唯一标识的资源包和对应 Service Worker 文件：
- 资源文件名嵌入内容哈希（如
app.a1b2c3.js），确保变更即新 URL，避免 CDN 或浏览器复用旧缓存 - Service Worker 脚本本身也带版本参数，例如
/sw.js?v=2.4.0，并在 HTML 中动态注入，防止被浏览器强缓存 - 生成一份资源清单（如
manifest-v2.4.0.json），明确列出该版本所有静态资源 URL，供 SW 安装阶段精准预缓存
CDN/网关层：按灰度策略分发 HTML 入口与版本上下文
灰度不是在 SW 里做判断，而是在资源入口处分流：
- 根据请求头（
x-gray-flag: canary）、Cookie（gray_version=2.4.0）或用户 ID 哈希，CDN 返回不同 HTML 模板 - 每个模板中包含对应版本的 SW 注册代码、资源引用路径（如
<script src="/js/app.a1b2c3.js"></script>）以及版本标识（如写入window.__SW_VERSION = '2.4.0'） - 关键点：同一时刻，一个用户只会看到一个版本的 HTML，也就只注册一个版本的 SW，天然隔离灰度环境
运行时快照管理：版本化缓存 + 自动降级逻辑
在 Service Worker 的 fetch 事件中，不依赖全局状态，而是基于当前上下文做精准快照匹配与兜底：
- 缓存命名强制绑定语义版本，如
static-v2.4.0和static-v2.3.1，install 阶段只写新缓存，activate 阶段清理非当前版本缓存 - fetch 拦截时，从页面注入的
window.__SW_VERSION或 Cookie 中读取当前期望版本，构造带版本的 cache key：request.url + '?v=' + version - 对关键资源（如首屏 JS/CSS/HTML）设置失败计数器：若连续 3 次 fetch 失败或响应状态异常（如 5xx），触发本地降级逻辑——改用上一已知稳定版本的缓存 key 尝试匹配，并记录
fallback: true到自定义 header 中供前端感知 - 降级后，前端可上报指标（如
gray_fallback_count），当某版本 fallback 率超阈值（如 5%），运维系统自动将该版本标记为“不稳定”，CDN 同步停止向新用户分发该 HTML 入口
回滚验证与可观测性保障
自动回滚不能只靠客户端，必须闭环验证：
- SW 在 activate 阶段调用
clients.matchAll()广播消息，通知已打开页面“已切换至 v2.3.1”，页面可主动刷新或局部重载关键模块 - 所有 fetch 处理中加入轻量日志（生产环境仅记录错误和 fallback 事件），通过
navigator.sendBeacon()上报到监控服务 - 配合前端埋点，统计各版本的白屏时长、资源加载成功率、fallback 触发率，形成灰度决策依据
