如何利用 MessageChannel 实现两个独立 iframe 间的高效实时通信？

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

无法使用MessageChannel在两个独立的iframe之间进行通信，无论是否同源、频率高低或延迟。

为什么 MessageChannel 在跨 iframe 场景下根本不可用

MessageChannel 的两个 port 对象（port1 和 port2）必须由同一方创建，并通过 postMessage 显式传递给目标上下文——但这个“传递”只在**同源且允许脚本执行的上下文间有效**。

当你尝试在 iframe A 中执行 new MessageChannel()，再调用 iframeB.contentWindow.postMessage(port2, '*') 时，浏览器会立刻拒绝：

• 跨域 iframe：控制台报错 Failed to execute 'postMessage' on 'MessagePort': Cannot send a MessagePort to a different origin.
• 同源但带 sandbox 属性的 iframe：若未声明 allow-scripts，脚本根本不运行，onmessage 监听器不会注册
• 同源无 sandbox 的 iframe：看似能传，但实际 port2 在进入 iframe B 后会被自动剥离（不可克隆），event.ports 为空数组，后续 port2.postMessage() 静默失败

高频低延迟 ≠ 必须用 MessageChannel

高频通信的瓶颈通常不在序列化本身，而在于事件调度、主线程争抢、消息无序或重复处理。裸用 postMessage 配合合理设计，完全可以满足多数高频场景（如实时协作光标、音视频同步状态、游戏帧状态更新）。

关键优化点包括：

• 使用 postMessage(data, targetOrigin, transferables) 传 ArrayBuffer 或 TypedArray，避免拷贝开销
• 在发送端用 requestIdleCallback 或 setTimeout(..., 0) 聚合短时间内的多条变更，合成单次消息
• 接收端用 event.source + event.origin 双重校验，拒绝非白名单来源的消息
• 对关键状态加轻量序列号（seq）和 ACK 回执，丢包时本地重发而非轮询

真正可行的 iframe 间通信链路结构

所有 iframe 必须通过父页面中转，这是唯一稳定、可控、可审计的路径。不要试图绕过父窗口直连。

初始化阶段需完成三件事：

• 每个 iframe 加载后主动向 parent 发送握手消息：{ type: 'handshake', id: 'editor-1', token: 'a1b2c3' }
• 父页面记录 event.source 引用与 id、origin、token 的映射关系
• 后续转发时，父页调用 targetIframe.contentWindow.postMessage(msg, targetOrigin)，不拼接、不修改原始数据结构

注意：event.source 是唯一能安全回传的窗口引用，iframe.contentWindow 在沙箱或跨域下可能为 null 或不可写。

MessageChannel 的价值只存在于“对象可直传”的上下文中（主线程 ↔ Worker、同源 iframe ↔ 父页）。一旦涉及两个独立 iframe，它就不是“没配好”，而是架构上不支持——这不是配置问题，是浏览器安全模型的硬性限制。