Service Worker 无法直接向已加载页面注入脚本，但可拦截 HTML 请求并修改响应内容，在 <head> 或 </body> 前插入监控脚本；该方式仅对首次加载或刷新有效，SPA 路由切换不触发；推荐结合页面主动加载与 SW 缓存协同实现。
Service Worker 本身无法直接向已加载的页面注入脚本（比如 <script> 标签），因为它运行在独立线程、无 DOM 访问权限，也不能操作当前页面的 window 或 document。所以“通过 Service Worker 拦截并动态注入全局异常监控脚本”这个说法存在常见误解——SW 不能主动往运行中的页面里塞 JS。
Service Worker 能做什么：拦截网络请求
SW 的核心能力是拦截 fetch 请求（包括 HTML 页面请求），并在响应返回前修改内容。因此，真正可行的方式是：
- 在 SW 中监听对 HTML 文件的请求（如
navigation类型或text/html响应） - 用
response.clone()获取原始 HTML 流 - 解析并修改 HTML 字符串，在
<head>或</body>前插入监控脚本的<script>标签 - 构造并返回修改后的新 Response
⚠️ 注意：该方式仅对通过 SW 控制的、首次加载或刷新的 HTML 有效；SPA 路由切换（如 Vue Router / React Router）不触发 HTML 请求，因此不会重复注入。
注入监控脚本需注意的关键点
动态注入不是简单拼字符串，否则容易破坏 HTML 结构或引发执行错误：
-
避免污染原始 HTML：优先使用流式解析（如
TextDecoder+ 正则谨慎匹配</head>或</body>），不推荐全量字符串 replace - 脚本必须内联或使用 defer/async：注入的监控脚本建议内联（减少额外请求），或确保远程脚本地址可被 SW 缓存/代理
-
避免重复注入：可在 HTML 中添加标记（如
data-monitor-injected），注入前先检查 - 不影响原始功能：注入逻辑需包裹在 try-catch 中，防止解析失败导致页面白屏
更可靠的做法：结合页面主动注册
单纯依赖 SW 注入有局限，推荐组合方案：
- SW 负责拦截 HTML 并注入轻量初始化代码（例如定义
window.__MONITOR_CONFIG或触发loadMonitor()） - 实际监控脚本由页面自己加载（如通过
import('./monitor.js')或document.createElement('script')） - 利用 SW 缓存监控脚本资源，确保离线可用、加载更快
这样既利用了 SW 的预加载与缓存优势，又规避了 HTML 注入的脆弱性，也便于调试和版本管理。
替代思路：Navigation Preload + 后端注入
如果项目可控后端，更稳定的方式是：
- 在服务端渲染（SSR）或静态生成时，直接将监控脚本写入 HTML 模板
- 启用 SW 的 Navigation Preload 加速首屏，但注入逻辑交给服务端
- SW 专注做资源缓存、离线 fallback 和 API 异常上报代理
这种分工清晰，稳定性高，适合中大型项目。
