如何利用 MessageChannel 实现跨域单页应用间的直接双向二进制通信？

本文共计783个文字，预计阅读时间需要4分钟。

无法完成。

MessageChannel 无法用于跨域通信

浏览器明确禁止将 MessagePort 实例传递给跨域环境。当你尝试通过 postMessage 向跨域 iframe 或窗口发送一个 port 时，浏览器会直接丢弃该 port，并在控制台报错：

Failed to execute 'postMessage' on 'MessagePort': Cannot send a MessagePort to a different origin.

这意味着 MessageChannel 的两个端口（port1 和 port2）根本无法在跨域上下文之间建立连接——通道连“起点”都不存在。

单页应用间跨域通信的合法路径只有 postMessage

跨域场景下，唯一被规范支持、各浏览器一致实现的通信机制是 window.postMessage。它由浏览器内核强制校验 origin，确保安全性，其他所有“绕过”方案均不成立：

• MessageChannel 必须依赖 postMessage 来“移交端口”，而移交本身在跨域时就失败
• SharedWorker 和 Service Worker 均受同源策略约束，无法被跨域页面注册或访问
• BroadcastChannel 仅限同源标签页/上下文，跨域频道无法创建或加入
• 二进制数据（如 ArrayBuffer）虽可随 postMessage 传输（通过 transfer 参数），但仍是基于 postMessage 的单向事件流，不是“双向通道”

所谓“高速”“双向”“绕过主线程”在跨域中是误导性概念

跨域通信本质是隔离的、受控的、事件驱动的。不存在“绕过主线程”的跨域通道——所有消息都需经主线程调度和安全检查：

• iframe.contentWindow 是 null 或受限的，无法直接访问对方 JS 上下文
• 没有共享内存、无指针、无底层 socket 暴露，所谓“二进制通道”只是对 ArrayBuffer 传输的误读
• 真正的双向交互必须靠双方约定协议（如带 id 和 replyTo 字段），由业务层模拟，而非 API 提供原生支持

可行的替代思路：同源中转 + 安全代理

如果确实需要类双向、低延迟体验，可考虑架构层面的解法，而非试图突破浏览器安全模型：

• 将跨域子应用部署到同一二级域名下（如 app1.yourdomain.com 和 app2.yourdomain.com），启用 document.domain（仅限传统子域，现代浏览器已弱化支持）或更推荐使用 same-site 配合 CORS 策略
• 引入一个同源的通信中继页（如 bridge.yourdomain.com/relay.html），由它分别与两个跨域页建立 postMessage 连接，做消息路由和协议转换
• 对高频小数据，用 localStorage + storage 事件做轻量同步（仅限同协议+同域名）；对大数据或实时性要求高者，走 WebSocket 服务端中转