不能直接用 ipcRenderer.send + ipcMain.on 做渲染进程间通信，因其需主进程中转，引入序列化、排队和上下文切换开销（延迟3–8ms），且不支持 ArrayBuffer 等可转移对象；应通过 MessageChannelMain 创建通道，用 webContents.postMessage 分发 port 并调用 port.start() 实现直连通信。
为什么不能直接用 ipcRenderer.send + ipcMain.on 做渲染进程间通信
因为 Electron 的 ipcRenderer.send 只能发给主进程，主进程再手动转发——这引入了额外的序列化、事件循环排队和上下文切换开销，实测端到端延迟常在 3–8ms 以上，且主进程成为单点瓶颈。更关键的是：消息无法携带 ArrayBuffer、ImageBitmap 等可转移对象，必须深拷贝。
MessagePort 在 Electron 渲染进程间通信的正确启动方式
必须通过主进程中转创建通道并分发 port，但**不走 IPC 消息体传输 port 对象本身**（那会失败），而是用 MessageChannelMain 创建后，把 port1 传给 A 窗口、port2 传给 B 窗口，靠 postMessage + onmessage 直连。关键约束：
- 主进程需启用
contextIsolation: false或确保 preload 脚本已暴露MessageChannelMain（Electron ≥ 20） - A 和 B 渲染进程必须使用同一份 preload 脚本（或至少都注入了
MessageChannelMain构造函数） - 不能在
webContents.send中发送 port 实例——必须用webContents.postMessage并设置transfer选项
主进程中创建与分发示例：
const { MessageChannelMain } = require('electron')
// 主进程某处（如窗口创建后）
const { port1, port2 } = new MessageChannelMain()
winA.webContents.postMessage('init-port', null, [port1])
winB.webContents.postMessage('init-port', null, [port2])
渲染进程接收 port 并建立双向监听
两个渲染进程都需监听 init-port 消息，并在收到后立即绑定 onmessage。注意：必须在接收到 port 后立刻调用 start()，否则消息会被丢弃。
A 窗口（renderer）：
window.addEventListener('message', (event) => {
if (event.channel === 'init-port' && event.ports?.length) {
const port = event.ports[0]
port.onmessage = (e) => console.log('A 收到:', e.data)
port.start() // 必须调用！
window.portToB = port // 保存引用供后续 postMessage
}
})
B 窗口同理，拿到自己的 port 后绑定反向监听。之后双方即可用 port.postMessage(data, [transferables]) 直传二进制数据，无 IPC 序列化开销。
容易被忽略的沙盒与 preload 配置陷阱
若启用了 sandbox: true（推荐），MessageChannelMain 默认不可用。必须在 preload 脚本中显式暴露：
// preload.js
const { contextBridge, MessageChannelMain } = require('electron')
contextBridge.exposeInMainWorld('MessageChannelMain', MessageChannelMain)
同时，webPreferences 中的 preload 路径必须指向该脚本，且两个窗口共用同一 preload 文件——不同 preload 会导致跨上下文 port 传输失败（权限隔离）。另外：contextIsolation 必须为 true 时，MessageChannelMain 无法直接暴露，需改用 ipcRenderer.invoke 在主进程中创建后再传 port，但此时首次建连仍有一次 IPC 延迟。
