MessageChannel是浏览器原生的双向低延迟通信通道，通过port1/port2端口实现跨环境（iframe/Worker）解耦通信，避免postMessage依赖上下文生命周期的问题。
MessageChannel 是什么，为什么它适合跨环境通信
MessageChannel 是浏览器原生提供的、用于在不同执行上下文之间建立双向、低延迟、无共享内存依赖的通道。它不依赖 postMessage 的全局事件监听（比如 window.onmessage），而是通过一对 port1 和 port2 端口实现点对点通信——这正是 HTML 运行环境（如 iframe、Web Worker）与主程序（主页面 JS）需要的干净解耦方式。
常见误区是直接用 window.postMessage 往 iframe 里发消息，但一旦 iframe 重载或嵌套多层，event.source 变得不可靠，且无法保证响应可回传。而 MessageChannel 的两个端口可分别移交：一个留在主页面，另一个传给 iframe 或 Worker，之后双方只认这个 port，不依赖上下文生命周期。
使用场景包括：
- Electron 中渲染进程（HTML）与主进程通信（需配合
contextBridge+ipcRenderer封装，但底层通道仍可由MessageChannel承载） - 沙箱 iframe 与父页面安全通信（
sandbox属性下window.parent被禁用，MessageChannel是少数被允许的通信手段） - Web Worker 与主线程高频数据交换（比反复调用
worker.postMessage()更可控）
如何把 port 传进 iframe 并建立双向链路
关键在于：iframe 必须在创建时就拿到 port，不能等 load 事件后再传——因为沙箱 iframe 可能禁止 contentWindow 访问。
立即学习“前端免费学习笔记（深入）”；
正确做法是用 iframe.contentWindow.postMessage() 配合 MessageChannel 初始化：
const channel = new MessageChannel();
const iframe = document.createElement('iframe');
iframe.src = 'sandboxed.html';
document.body.appendChild(iframe);
<p>// 立即发送 port 给 iframe（即使 iframe 还没加载完，message 会排队）
iframe.contentWindow.postMessage('INIT', '*', [channel.port2]);</p><p>// 主页面监听自己的 port1
channel.port1.onmessage = (event) => {
console.log('收到来自 iframe 的数据：', event.data);
};
channel.port1.start(); // 必须 start 才能收消息iframe 内（sandboxed.html）要立刻接收并启用 port：
window.onmessage = (event) => {
if (event.data === 'INIT' && event.ports.length > 0) {
const port = event.ports[0];
port.onmessage = (e) => console.log('收到主页面消息：', e.data);
port.postMessage({ ack: true }); // 立即回传确认
port.start();
}
};容易踩的坑：
-
postMessage第三个参数必须是[port]数组，漏掉方括号或写成port本体，port 就不会被传输 - iframe 启用
sandbox="allow-scripts"是必须的，否则onmessage不触发 - 没调用
port.start()→ 消息永远不触发onmessage，控制台也无报错
在 Web Worker 中使用 MessageChannel 传递结构化数据
Worker 场景下，MessageChannel 最大价值是避免序列化开销。普通 worker.postMessage(obj) 会深拷贝（structured clone），而 MessageChannel 的 port 可以直接 transfer，零拷贝传递 ArrayBuffer、ImageBitmap 等。
主页面代码：
const worker = new Worker('worker.js');
const channel = new MessageChannel();
<p>// 把 port1 给 worker，注意 transfer
worker.postMessage({ type: 'SET_PORT' }, [channel.port1]);</p><p>// 发送大数据（比如 canvas.toBlob 产出的 ArrayBuffer）
const buf = new ArrayBuffer(10 <em> 1024 </em> 1024);
channel.port2.postMessage({ data: buf }, [buf]); // buf 被转移，主页面不能再访问worker.js 中：
let port;
self.onmessage = (e) => {
if (e.data.type === 'SET_PORT') {
port = e.ports[0];
port.onmessage = handleWorkerMessage;
port.start();
}
};
<p>function handleWorkerMessage(e) {
const { data } = e.data;
// data 是已转移的 ArrayBuffer，可直接用于 WebGL 或 WASM
}注意点：
- transfer 的对象（如
ArrayBuffer）在发送后主页面立即变为byteLength === 0，不可再读 —— 这不是 bug，是设计行为 - Worker 内不能用
new MessageChannel()然后反向传 port 给主线程（因 Worker 无contentWindow），必须由主线程创建并传出 - Chrome 120+ 对 transfer 的
ArrayBuffer大小无硬限制，但 Safari 仍建议单次
Electron 渲染进程与主进程间能否直接用 MessageChannel
不能直接用。Electron 的 ipcRenderer 和 ipcMain 是基于 Node.js IPC 的封装，不暴露底层 port 接口。MessageChannel 是纯浏览器标准 API，运行在渲染进程的 JS 环境中，而主进程是 Node.js 环境，二者没有共享的 MessagePort 实现。
但可以桥接：
- 在渲染进程创建
MessageChannel，把port2通过ipcRenderer.invoke()“注册”到主进程（实际是存个 ID 映射） - 主进程收到消息后，用
webContents.send()把数据推回渲染进程，再由渲染进程的port1收到 - 更稳妥的做法仍是用
contextBridge暴露一个封装函数，内部用ipcRenderer，把MessageChannel当作渲染进程内部的“消息总线”，不穿透到主进程
真正容易被忽略的是：很多人试图在 preload.js 里 new MessageChannel 然后挂到 window 上，结果发现 iframe 里拿不到 port —— 因为 preload 注入的是独立上下文，iframe 的 globalThis 和 preload 的 globalThis 不同，port 无法跨 context 传递。必须用 postMessage + transfer 显式移交。
事情说清了就结束。
