web worker 严格遵循同源策略，仅允许加载与当前页面协议、域名、端口完全一致的脚本，否则抛出 securityerror；因其共享页面 origin，可访问 cookie、fetch、indexeddb 等敏感资源，跨域加载将破坏 csp 与沙箱隔离。
web worker 本身受同源策略严格约束——它只能加载与当前页面完全同源（协议、域名、端口三者一致）的脚本文件。这不是可选行为，而是浏览器强制执行的安全限制。一旦尝试用 new worker('https://api.example.com/worker.js') 或甚至 new worker('//cdn.example.com/worker.js')，浏览器会直接抛出 securityerror，根本不会发起网络请求。
为什么 Worker 要单独 enforce 同源？
Worker 运行在独立线程，但共享页面的 origin 上下文。它虽不访问 DOM，却能读取和操作同源下的 Cookie、调用 fetch、访问 IndexedDB，甚至通过 importScripts() 加载其他脚本。若允许跨域加载 worker 脚本，攻击者就能把恶意逻辑注入到你站点的可信执行环境中，绕过 CSP 和沙箱隔离。所以浏览器把它和 XMLHttpRequest 视为同等敏感——必须同源。
开发阶段常见跨域报错场景
本地开发时最容易踩坑的几个情况：
- 前端跑在
http://localhost:3000，Worker 脚本路径写成相对地址'./utils/worker.js'—— 正常；但若误写成'http://localhost:5000/utils/worker.js'，即使本机服务开着，也会因端口不同被拒 - Vite 或 Webpack Dev Server 启用了 HTTPS 代理，但 Worker 构造函数仍用 HTTP 地址，协议不一致即跨域
- 使用
importScripts('https://unpkg.com/some-lib.js')在 Worker 内部动态加载外部库——明确违反同源，100% 失败 - 通过
Blob URL创建 Worker 时，Blob 内容含跨域资源引用（如fetch('https://xxx')不受限，但importScripts('https://yyy')仍受限）
安全可行的开发期绕过方式
不能“绕过”同源策略本身，但可以调整资源部署方式，让 Worker 脚本始终落在同源下：
-
统一开发服务器端口：让前端服务和 API 服务都走同一端口（如全走 3000），或用反向代理（Nginx/Vite proxy）将
/api/代理到后端，Worker 仍只加载./worker.js -
用 Blob URL 动态生成 Worker：把 Worker 代码作为字符串，用
Blob构造同源 URL，再传给new Worker()。这样脚本内容来自当前页面上下文，天然同源：const code = `self.onmessage = () => self.postMessage('from blob');`;<br> const blob = new Blob([code], { type: 'application/javascript' });<br> const url = URL.createObjectURL(blob);<br> const worker = new Worker(url); -
构建时内联或复制 Worker 文件：在打包流程中，把 Worker 脚本作为模块处理（如 Vite 的
?worker后缀），由构建工具自动注入同源路径，避免手写 URL 出错
绝对不要尝试的“伪解决方案”
这些做法要么无效，要么引入严重风险：
- 试图在 Worker 内用
document.domain = 'example.com'—— Worker 没有document对象，语法错误 - 用 CORS 配置让后端返回 Worker 脚本，并设
Access-Control-Allow-Origin: *—— 浏览器根本不检查 CORS，只认同源，配置无效 - 把 Worker 脚本放在 CDN 并用
<script type="module"></script>加载后转成字符串 —— 模块加载本身跨域失败，无法获取源码 - 用 Node.js 启动本地 HTTP 服务并设置
Originheader 欺骗浏览器 —— 无意义，同源判断发生在客户端，header 不影响 origin 解析
