MessageChannel实现两个独立iframe间高频低延迟通信

先给出一个核心结论：MessageChannel 无法用于两个独立 iframe 之间的通信，无论这两个 iframe 是否同源、是否满足高频或低延迟需求。这一限制并非配置问题，而是浏览器安全模型的硬性规定。

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

关键在于 MessageChannel 的两个端口对象（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，则 iframe 内的脚本不会执行，onmessage 监听器自然无法注册。
• 同源无沙箱的 iframe：此种情况看似可以传递，但实际上 port2 进入 iframe B 后会被浏览器自动剥离（不可克隆），导致 event.ports 变为空数组，后续所有通过 port2.postMessage() 的通信都会静默失败。

因此，无论哪种情况，这条路径均无法走通。

高频低延迟 ≠ 必须用 MessageChannel

许多开发者追求 MessageChannel，是看中其理论上更低的通信开销。但事实上，高频通信的瓶颈往往不在于序列化本身，而在于事件调度、主线程争抢、消息无序或重复处理等环节。

直接使用 postMessage，配合合理的设计，完全能够满足绝大多数高频场景的需求，例如实时协作光标、音视频同步状态、游戏帧状态更新等。

关键在于优化策略：

• 利用可转移对象：使用 postMessage(data, targetOrigin, transferables) 传递 ArrayBuffer 或 TypedArray，可以避免数据拷贝的巨大开销。
• 消息聚合：在发送端，利用 requestIdleCallback 或 setTimeout(..., 0) 将短时间内产生的多条状态变更聚合成单次消息发送，减少通信次数。
• 来源校验：接收端务必使用 event.source 和 event.origin 进行双重校验，只处理来自白名单来源的消息，确保安全。
• 轻量级可靠性保证：对关键状态消息添加轻量的序列号（seq）和 ACK 回执机制。一旦检测到丢包，由发送方在本地重发，而不是让接收方盲目轮询。

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

那么，两个独立 iframe 之间到底该如何通信？答案是：所有 iframe 必须通过父页面进行中转。这是唯一稳定、可控且可审计的路径，不应试图绕过父窗口建立直连。

一个健壮的实现，在初始化阶段需要完成三件事：

• 主动握手：每个 iframe 加载完成后，主动向 parent 发送一条握手消息，例如 { type: 'handshake', id: 'editor-1', token: 'a1b2c3' }。
• 建立映射：父页面接收到握手消息后，记录下 event.source（这是安全的窗口引用）与 iframe 的 id、origin、token 的映射关系。
• 消息转发：后续当 iframe A 需要向 iframe B 发送消息时，先将消息发给父页面。父页面根据目标 ID 找到对应的 targetIframe.contentWindow，调用 targetIframe.contentWindow.postMessage(msg, targetOrigin) 进行转发。注意，父页面应尽量不拼接、不修改原始数据结构，只做纯粹的“邮差”。

这里有一个重要细节：event.source 是唯一能安全回传的窗口引用。在某些沙箱或跨域场景下，直接通过 iframe.contentWindow 获取的引用可能为 null 或不可写。

总而言之，MessageChannel 的价值仅存在于“对象可以直接传递”的上下文中，比如主线程与 Web Worker 之间，或者同源的 iframe 与父页面之间。一旦涉及两个独立的 iframe，它就不是“没配置好”的问题，而是架构上根本不支持。理解这一点，有助于避免许多徒劳的尝试。