service worker 本身不支持灰度发布，需在 fetch 事件中动态读取 cookie/header/url 路径获取灰度标识，结合版本化缓存键（如 url + '?v=' + version）和带版本号的 sw 注册路径协同实现。
Service Worker 本身不能“建立灰度发布”，它只是执行者；真正起作用的是 fetch 事件中对请求 URL 的重写 + 外部灰度标识的读取 + 缓存键的版本化设计。
fetch 事件里怎么读取灰度标识
install 阶段完全读不到 cookie、localStorage 或 header，所以灰度开关必须在 fetch 事件中动态获取。常见方式有三种：
- 从
document.cookie解析，比如读取gray=beta（注意：需确保页面已注入该 cookie，且 SW 注册时机不早于 DOM 加载） - 检查
request.headers.get('x-gray-flag')，这要求后端（如 Nginx / OpenResty）在转发请求时带上该 header - 用
request.url路径判断，例如匹配/beta/前缀，适合前端主动跳转灰度页的场景
错误做法是把灰度逻辑写进 install 事件——此时 request 对象还不存在，self.skipWaiting() 也解决不了分流问题。
如何让同一资源在不同灰度通道下走不同缓存
直接用 caches.match(request) 会复用裸 URL，导致 beta 用户加载了 stable 版本的 JS。必须改造 cache key：
self.addEventListener('fetch', event => {
const url = new URL(event.request.url);
const version = getGrayVersion(event.request); // 自定义函数，返回 'stable' 或 'beta'
const cacheKey = url.origin + url.pathname + '?v=' + version;
event.respondWith(
caches.match(cacheKey).then(res => res || fetch(event.request))
);
});
关键点：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- cache key 必须显式拼入版本标识，不能只靠 URL 参数（CDN 可能忽略）
- 静态资源路径最好带哈希（如
main.a1b2c3.js），否则 CDN 和浏览器可能缓存错版本 - 每次灰度切换后，旧缓存不会自动清理，需在
activate阶段手动caches.delete()不相关缓存名
为什么注册 sw.js 时必须带版本参数
浏览器对 navigator.serviceWorker.register('/sw.js') 有强缓存，即使你更新了文件内容，只要 URL 不变，就不会重新 fetch。后果是：
- 灰度用户永远注册旧版 SW，无法响应新分流逻辑
- 回滚时无法强制降级，因为新版 SW 已激活且没提供退路
正确做法是在 HTML 中动态注入带版本号的注册路径：
<script> const swUrl = '/sw.js?v=' + (isGrayUser ? 'beta-1.2.3' : 'stable-1.2.2'); navigator.serviceWorker.register(swUrl); </script>
同时配合 CDN 配置：对 /sw.js 路径禁用缓存，或设置极短 max-age，否则 Nginx / Cloudflare 可能拦住这个请求。
灰度失败时最常被忽略的三个点
实际线上踩坑发现，90% 的灰度失效不是逻辑写错，而是这三个地方没对齐：
- 前端读取的灰度标识（如 cookie 名）和后端注入的不一致，比如一个叫
gray_flag，一个写成gray-flag - SW 的
scope设置过宽（如/），导致多个子应用共用一个缓存空间，互相污染 - HTML 入口文件本身没做灰度分流，所有用户都加载了同一份
index.html，自然也就注册了同一个 SW 脚本
灰度的本质是链路对齐：HTML → SW 脚本 → 请求 header/cookie → fetch 分流 → 缓存键 → 资源路径，任意一环断开，整个策略就失效。
