service worker 无法动态修改 dom 中的静态资源路径，因其运行在无 dom、无 window 的独立线程，不能访问或改写 或 标签；可行方式是在 fetch 事件中识别请求并映射到带版本/哈希的目标路径，配合构建时注入真实文件名与 install 阶段预缓存实现路径控制。
Service Worker 无法动态修改 DOM 中的静态资源路径。
原因很直接：SW 运行在独立线程，不访问 DOM
Service Worker 是一个无 DOM、无 window 对象的后台脚本。它不能读取页面当前的 <script src="app.js"></script> 或 <link href="style.css">，更不能去改写这些标签的 src 或 href 属性。所谓“拦截请求后修改路径”，实际是指在请求发出**之后**、响应返回**之前**，对请求 URL 做重定向或响应替换——但这个过程对 HTML 源码里的原始路径完全无感。
真正可行的路径控制方式是请求时匹配与响应时映射
你不能改 DOM，但可以控制浏览器“发出去的请求”最终命中哪个资源。关键靠两点：
-
预缓存阶段用目标路径：install 时缓存
/js/app-v2.3.1.js，而不是/js/app.js -
fetch 拦截中做精准 URL 映射：当页面请求
/js/app.js时，在 fetch 事件里识别它，并主动 fetch/js/app-v2.3.1.js（或从对应缓存中 match），再把响应返回给页面——页面仍认为自己加载的是app.js，实际用的是带版本的新文件
推荐落地做法：构建时注入 + SW 路由兜底
想让 app.js 指向最新版，不要靠 SW 改 DOM，而是结合构建和运行时协同：
- 构建工具（如 Webpack/Vite）在生成 HTML 时，把
app.js替换为带哈希或版本号的路径，例如app.a1b2c3.js - Service Worker 注册在根路径，install 阶段缓存这个带哈希的真实路径
- fetch 事件中用正则识别
/\.js(\?.*)?$类请求，再通过caches.match()查找是否已有对应缓存条目；若没有，可 fallback 到一个“版本路由表”（如 JSON 文件）动态查出应加载的物理路径
注意几个典型误区
以下操作都不可行或会引发问题：
- 在 SW 里试图用
document.querySelector('script')—— 报错，没有 document - 监听
fetch后用event.request.url.replace('app.js', 'app-v2.js')再 fetch —— 请求已发出，URL 无法中途篡改；只能在匹配后返回另一个响应 - 缓存名用
static而不是static-v2.3.1—— 版本切换时旧页面可能读到新内容，导致执行错乱
