在前面的章节中，我们反复强调 Electron 应用由主进程与渲染进程构成，并且它们之间的任何协作都必须通过 IPC 来完成。那么，这些 IPC 调用最终是怎样在底层传递的？为什么一条 ipcRenderer.send 能够跨越进程边界精确抵达主进程？本节就会把这些“黑盒”拆开，带你了解两套实际的底层机制：来自 Chromium 的 Mojo 消息管道，以及 Node.js 自带的进程通信能力。
4.2.1 Chromium Mojo 消息管道：Electron IPC 的真正骨架
如果你打开 Electron 的源码，会在主进程和渲染进程之间看到大量的 mojo、interface、pending_receiver 等字眼。这些东西就是 Chrome 团队开发的一套进程间通信框架 —— Mojo。
Mojo 是一个用于在浏览器多进程架构（浏览器进程、渲染进程、GPU 进程等）之间高效传递消息的运行时。它的设计目标非常明确：用轻量的接口定义语言描述一个服务，然后自动生成 C++ 和 JavaScript 的绑定代码，让不同进程里的对象可以相互调用方法、传递数据，就像调用本地函数一样。
这套机制的关键构成可以简化为三层：
- 接口定义（
.mojom文件）
就像定义一个 API 契约，Mojo 允许你用类 TypeScript 的语法描述一个服务包含哪些方法：
interface ElectronApi {
SendIpc(string channel, array<uint8> args) => ();
}
Electron 内部就定义了大量这样的接口，用于封装窗口操作、菜单回调、消息发送等能力。
- 绑定层（Binding Layer）
根据接口定义自动生成的 C++ 和 JavaScript 胶水代码，负责序列化参数、投递消息队列、调用对端方法。这层代码对开发者而言几乎零感知 —— 当你调用 ipcMain.on(...) 时，Node.js 侧走的就是 Mojo 生成的 C++ 绑定；渲染进程里的 ipcRenderer.send(...) 则对应 JavaScript 绑定。
- 消息管道（Message Pipe）
这是 Mojo 的核心抽象。你可以把管道想象成一条带缓存的全双工通道，两端分别连接不同进程上的对象。无论是主进程还是渲染进程，只要有管道的端点，就能往里面写消息，另一端会收到通知并读取数据。管道的实现依赖操作系统提供的底层 IPC 原语 —— Windows 上可能是命名管道或共享内存，Linux/macOS 上是 Unix Domain Socket 或 Mach Port —— 但这些细节对 Electron 开发者来说全被 Mojo 盖住了。
实际的一次 IPC 调用（例如渲染进程请求打开文件对话框）大致经历：
- 渲染进程调用
ipcRenderer.invoke('open-file')。 ipcRenderer内部将请求序列化为一个消息包，通过 Mojo 管道发送给主进程。- 主进程的 Mojo 端点接收到消息，交给注册了相应通道的监听器（也就是
ipcMain.handle('open-file', ...)）。 - 主进程的处理函数执行并返回结果，结果同样经过 Mojo 管道反向传回渲染进程。
- 渲染进程的
ipcRenderer.invoke拿到结果，Promise 被 resolve。
整个过程是异步的，数据在管道中传递时可以携带字符串、Buffer、JSON 对象等，Mojo 会自动处理序列化和反序列化。更重要的是，这条通道是专属于 Electron 框架内部的，它并不依赖 Chrome 扩展机制或者网络端口，因此在安全性和性能上都经过刻意优化。
为什么 Electron 要费这么大力气用 Mojo，而不是直接复用 Node.js 原生 IPC？答案就在多进程架构上：Chromium 本身已经通过 Mojo 管理了它内部所有组件（如 GPU 进程、网络服务）之间的通信，Electron 不过是顺理成章地在这个体系里挂上了自己的接口而已。这既减少了重复造轮子的风险，又确保了渲染进程在沙箱中仍然能够用安全、受控的方式请求系统能力。
4.2.2 Node.js 进程通信：老牌可靠的 IP通道
除了 Mojo 之外，Electron 应用里经常会遇到另一种通信需求：主进程需要派生一个纯 Node.js 的子进程来完成计算密集或需要长时间运行的任务。这时，Node.js 自带的进程间通信机制就派上了用场。
Node.js 提供了两种使用 IPC 的典型方式：
child_process.fork()的消息通道
当你用 fork() 启动一个 Node.js 脚本时，父进程和子进程之间会自动建立一条 IPC 通道（底层在 *nix 上是 Unix Domain Socket，在 Windows 上是对应的管道实现）。父子双方可以通过 process.send(message) 和 process.on('message', callback) 互发消息。
在 Electron 应用中，如果有一个耗时且不能阻塞主事件循环的任务（比如大规模图像压缩、对本地 SQLite 数据库做全量分析、运行 Electron 内嵌 Node.js 无法满足的定制版本，甚至调用 Python 脚本再传回结果），你完全可以在主进程里 fork 一个子脚本，把任务分发给它，并通过消息通道获取进度和结果。
这种方式的优势在于：
- 子进程崩溃不会影响主进程或渲染窗口。
- 消息传递机制成熟稳定，自动处理序列化（支持 JSON 和 Buffer）。
- 与 Electron 的 IPC 相互独立但又可以配合使用：主进程可以作为“中转站”，把渲染进程的请求转发给子进程，处理完毕后再将结果经由 Mojo 通道返回给渲染进程。
stdin/stdout管道与网络端口
虽然文件描述符重定向更为底层，但在一些追求极高传输效率或需要兼容非 Node.js 子进程（例如用 C++/Go 编写的辅助程序）的场景下，主进程也可以通过 child_process.spawn 启动可执行文件，利用标准输入输出或 TCP/UDP 本地端口进行通信。这种方式的数据格式完全由你定义（比如换行分隔的 JSON），虽然没有 fork 的消息通道方便，但胜在灵活，可以跨越任意语言边界。
在真实的 Electron 项目中，Node.js 进程通信经常被用来实现“旁路”辅助进程，比如：
- 一个专门负责文件索引的后台子进程，持续扫描指定目录并更新数据库。
- 一个运行本地 HTTP API 的 Express 服务器，为网页前端提供 REST 接口。
- 一个 WebSocket 客户端，和外部硬件设备保持长连接，再把设备事件报告给主进程。
以上所有这些场景中，Mojo 负责主与渲染进程的核心 UI 指令通路，Node.js IPC 负责主进程与后台辅助进程的数据交换。两条通道各司其职，共同构成了 Electron 中完善且灵活的进程协作体系。
小结：
- Chromium Mojo 是 Electron IPC 的“高速公路”，它建立在已有跨进程基础设施上，保证了主渲染通信的高效与安全。
- Node.js 的进程通信（尤其是
fork的消息通道）为主进程提供了与子进程交互的标准化手段，适合解耦耗时任务或集成系统级服务。 - 在实际开发中，你基本不需要直接触碰 Mojo 的细节，只要坚持使用
ipcMain/ipcRenderer就能搭上它带来的便利；而 Node.js 进程通信则回归原始却很可靠的用法，在需要横向扩展任务时随时可以启动后台进程。
理解了这两种底层机制的关系之后，后续当你遇到“为什么 Electron 应用可以这么顺畅地跨进程调度功能”时，答案就会非常自然——因为整套系统从架构第一天起就是围绕高效通信而设计的。