MessageChannel 是 HTML5 提供的高效跨上下文通信机制，通过专属 MessagePort 实现主子应用双向通信，需正确创建、传输、绑定端口并及时关闭以防泄漏，可作为微前端高频场景的补充通信方案。
MessageChannel 是 HTML5 提供的原生跨上下文通信机制，适合在微前端中连接主应用与子应用（尤其是 iframe、Web Worker 或不同 sandbox 环境下的 JS 上下文），它比 postMessage 更高效、更可控——因为通道两端拥有专属的 MessagePort，无需全局监听和字符串化判断，避免了事件冒泡、重复解析和竞态问题。
一、创建并分发 MessagePort 实例
主应用负责初始化 MessageChannel，并将其中一个端口（port2）传递给子应用；另一个端口（port1）保留在主应用中用于监听和发送。关键在于：端口只能被传输一次，且必须在子应用上下文创建前完成传递。
- 主应用中创建通道：const channel = new MessageChannel();
- 通过 iframe 的 postMessage 将 port2 发送给子应用（需指定 targetOrigin 和 transfer 参数）：iframe.contentWindow.postMessage({ type: 'INIT_PORT' }, '*', [channel.port2]);
- 子应用在 message 事件中接收并启用端口：event.ports[0].start();，之后即可用该 port 收发结构化数据
二、绑定端口并建立双向通信协议
主应用和子应用各自对持有的 port 调用 start() 后，可使用 onmessage 监听，postMessage 发送。建议封装统一通信层，避免裸用原生 API。
- 主应用监听子应用消息：channel.port1.onmessage = ({ data }) => { /* 处理子应用指令 */ };
- 子应用发送消息示例：port.postMessage({ type: 'ROUTE_CHANGE', payload: '/user/profile' });
- 为提升可维护性，建议约定消息格式：包含 type（动作标识）、id（用于响应追踪）、payload（业务数据）、from（来源标识）
三、处理生命周期与端口释放
微前端中子应用频繁挂载/卸载，若未正确关闭 MessagePort，会导致内存泄漏和残留监听器。务必在子应用卸载时主动关闭端口。
立即学习“前端免费学习笔记（深入）”；
- 子应用销毁前调用：port.close();
- 主应用可在接收到子应用的 DISPOSE 消息后，也调用 channel.port1.close();
- 避免在 port 关闭后继续调用 postMessage，否则会静默失败；可通过 port.onmessageerror 捕获传输异常
四、与主流微前端框架集成建议
qiankun、micro-app、Garfish 等框架默认基于 postMessage，但都支持自定义通信方式。可将 MessageChannel 封装为插件式通信适配器：
- 在 qiankun 的 beforeLoad 钩子中创建 channel，通过 props 注入子应用；子应用在 mount 后接管 port
- 用 WeakMap 缓存每个子应用对应的 port，按 appKey 管理生命周期，避免端口混淆
- 不推荐完全替代框架内置通信，而是作为高频率、低延迟场景（如实时状态同步、拖拽反馈、性能埋点）的补充通道
