Service Worker 不能直接测速，但可作为调度中枢实现多 CDN 切换：前端用 fetch + performance.now() 测各 CDN 的 HTTP 延迟，SW 根据结果重写请求 URL 并隔离缓存。
Service Worker 本身不能直接发起网络测速（比如 ping 或 TCP 连接测试），也不具备主动探测多个 CDN 节点延迟的能力——它运行在浏览器沙箱中，受限于同源策略、无权创建原始 socket、无法测量真实 RTT。但你可以用它作为“调度中枢”，配合前端测速逻辑与 CDN 路由决策，实现基于实测延迟的多 CDN 切换。关键不在 SW 做测速，而在它控制资源请求走向哪个 CDN 域名。
测速必须由前端 JavaScript 完成
真实网络延迟需靠 fetch + performance.now() 或 XMLHttpRequest 测量 HTTP 请求耗时（模拟用户真实访问路径）。建议选择轻量探针资源（如 /ping?ts=xxx 或一个 1KB 的空 JSON 文件），部署在每个目标 CDN 域名下：
- cdn-a.example.com/ping
- cdn-b.example.com/ping
- cdn-c.example.com/ping
测速脚本应并行发起 3–5 次请求，剔除异常值后取中位数，避免单次抖动干扰判断。注意设置超时（如 3000ms），防止卡死。
Service Worker 负责路由分发与缓存隔离
SW 不测速，但可依据测速结果决定后续所有静态资源请求该走哪个 CDN 域名。实现要点：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 将测速结果（如
"preferredCDN": "cdn-b"）存入localStorage或indexedDB - 在 SW 的
fetch事件中读取该偏好，重写请求 URL：request.url.replace(/^(https?:\/\/)cdn-\w+\.example\.com/, '$1cdn-b.example.com') - 为不同 CDN 域名使用独立缓存名（如
caches.open('cache-cdn-b-v1')），避免混用导致资源错乱
CDN 层需支持域名级灰度与健康探测
仅靠前端测速不够可靠，需后端/CDN 配合保障可用性：
- 每个 CDN 域名背后应配置健康检查（HTTP 200 + 响应时间阈值），自动屏蔽异常节点
- HTML 入口页需动态注入当前优选 CDN 域名（例如通过服务端模板或边缘脚本），确保首次加载就走最优链路
- CDN 控制台开启「缓存键包含 Host 头」，否则不同 CDN 域名的同一资源可能被错误复用缓存
避免常见陷阱
实际落地中最容易出问题的几个点：
- 测速期间用户已开始加载资源 → 应在页面加载前完成（如放在
的内联脚本中），或采用“先加载、再切换”的平滑降级策略 - Service Worker 缓存了旧 CDN 域名下的资源 → 每次切换 CDN 时，需显式删除旧缓存（
caches.delete()），并触发 SW 更新（self.skipWaiting()+clients.claim()） - HTTPS 混合内容限制 → 所有 CDN 域名必须启用有效 HTTPS，且证书可信，否则 fetch 会失败
