web worker 无法跨域加载脚本是浏览器强制的安全限制。因其共享页面 origin 上下文，允许跨域将破坏 csp 和沙箱隔离；可行方案仅两种：同源部署或 blob url 动态构造，且需注意内存泄漏与第三方代码风险。
Web Worker 无法直接跨域加载脚本——这不是兼容性问题，而是浏览器强制执行的安全红线。只要协议、域名、端口三者中任一不同，new Worker('...') 就会立即抛出 SecurityError，根本不会发出网络请求。
为什么必须同源？
Worker 虽不操作 DOM，但共享页面的 origin 上下文：能读取同源 Cookie、调用 fetch、访问 IndexedDB，甚至通过 importScripts() 加载其他脚本。若允许跨域加载，攻击者就能把恶意逻辑注入你站点的可信执行环境，绕过 CSP 和沙箱隔离。因此，它的同源要求和 XMLHttpRequest 一样严格。
真正可行的绕过方式只有两种
所谓“绕过”，不是突破策略，而是让脚本内容以同源形式进入 Worker：
-
统一部署路径：将 Worker 脚本与主站一起托管（如都走
/static/worker.js），或用反向代理（Vite proxy / Nginx）把远程资源映射到同源路径下 -
Blob URL 动态构造：主线程用
fetch拉取支持 CORS 的远程脚本（如 jsDelivr、unpkg），转为 Blob 后生成同源临时 URL：const blob = await resp.blob();<br> const url = URL.createObjectURL(blob);<br> const worker = new Worker(url);
关键限制与风险点
Blob 方案看似灵活，但存在几个硬约束：
- Worker 内部仍不能
importScripts('https://xxx')—— 那是 Worker 自己发起的跨域请求，CORS 不起作用 - 所有依赖必须提前内联进初始脚本，或改用
fetch+eval（极不推荐） - Blob URL 是一次性地址，每次调用
createObjectURL都生成新 URL；不用时必须手动URL.revokeObjectURL(url)，否则内存泄漏 - 加载第三方脚本等于执行第三方代码——务必确认来源可信，避免引入 XSS 或数据窃取风险
不推荐的“方案”
以下做法实际无效或存在严重隐患：
- 试图用 JSONP 或
<script></script>标签在 Worker 中加载——Worker 环境不支持 DOM 操作，document不存在 - 依赖
co-web-worker等封装库——它只是对 Blob 方案的语法糖，底层仍是 fetch + createObjectURL，未改变安全模型 - 在生产环境设
Access-Control-Allow-Origin: *开放 Worker 脚本——等同于主动放弃同源保护，违背设计初衷
