web worker 不支持跨域通信，必须同源；所谓“跨域worker通信”实为混淆，真实场景一是iframe跨域通信（优化postmessage）、二是子域名共享状态（用sharedworker或后端代理）。

Web Worker 本身**不支持跨域通信**——这是浏览器强制的安全限制。Worker 脚本必须与主页面同源（协议、域名、端口完全一致），否则 `new Worker('...')` 会直接抛出 `SecurityError`。所以严格来说，**不存在“Worker 与主线程的跨域通信”这一场景**，也就谈不上优化其开销。 但如果你实际遇到的是以下两类常见混淆情况，对应的真实问题和解法如下：

✅ 场景一：误把 iframe 跨域通信当成 Worker 通信

例如在嵌入第三方 iframe 的页面中，试图用 Worker 协助主页面与 iframe 通信——此时真正的跨域通信发生在 window ↔ iframe 之间，Worker 只是内部工具，不参与跨域链路。

优化重点不是 Worker，而是 postMessage 安全通信本身：

智谱清言

智谱清言是一款AI工具，智谱推出的全能AI助手。

下载

• 只向可信 origin 发送消息，接收时严格校验 event.origin 和 event.source
• 避免传递大对象；如需传数据，先序列化为精简 JSON，剔除冗余字段
• 对高频小消息做合并（例如将 10 次状态更新聚合成一次批量 payload）
• 不用 JSON.stringify / parse 做额外序列化——postMessage 本身已用结构化克隆，重复处理反而增加开销

✅ 场景二：想让多个子域名共享 Worker 状态（如 a.example.com ↔ b.example.com）

这属于「同站（same-site）但不同源」，Worker 仍无法直连。可行替代方案是：

• 用 SharedWorker + 同一注册 URL：部署一个统一入口（如 https://shared.example.com/worker.js），让各子域名页面都加载它；只要协议+主域名一致（且满足 same-site 策略），SharedWorker 实例可被复用
• 借助 localStorage + storage 事件 + 同站 iframe 中转：在根域名（example.com）下挂一个隐藏 iframe，作为跨子域通信桥接层，Worker 仅与同源 iframe 通信
• 后端代理中转：Worker 调用 fetch 请求到统一 API 域名（如 api.example.com），由服务端完成状态同步，规避前端跨域

⚠️ 注意：Transferable Objects、SharedArrayBuffer 等优化手段仅适用于同源 Worker

它们能大幅降低大数据传输成本，但前提是主线程与 Worker 运行在同一源下。一旦涉及跨域，这些机制根本不可用——浏览器会在创建 Worker 阶段就拦截，不会进入通信阶段。

不复杂但容易忽略。