11. IPC 通信基础

前面几章反复提到一个词：IPC（Inter-Process Communication，进程间通信）。它是 Electron 应用里最底层的协作机制。本章先把概念讲透，后面的 contextBridge、ipcMain、ipcRenderer 才好理解。

本节目标

理解为什么主进程与渲染进程必须靠 IPC 通信。
看清「进程隔离」到底隔离了什么能力。
掌握「消息通道（channel）」的概念与命名习惯。
区分同步通信与异步通信的本质差异。
明白为什么不能在不同进程间直接共享对象。

11-1 为什么需要 IPC

Electron 的进程各有分工。主进程握着操作系统权限：创建窗口、读写文件、调系统对话框。渲染进程跑网页，负责界面与交互，但默认没有 Node.js、碰不到系统。

问题是：界面上的按钮想「打开一个系统文件框」，这活只有主进程能干。可按钮在渲染进程里。两个进程不能直接互相调用函数，怎么办？答案是发消息——这就是 IPC。

没有 IPC，渲染进程只能干瞪眼，主进程也收不到界面指令。IPC 把「界面请求」和「系统能力」缝在一起，是功能型桌面应用的命脉。

11-2 进程隔离意味着什么

隔离不是 Electron 故意为难你，而是安全与稳定的需要。每个渲染进程崩了，不应拖垮整个应用；网页内容不可信，也绝不能直接拥有系统权限。

这种隔离带来一个硬事实：主、渲两进程运行在不同的 V8 实例，内存不共享。你在主进程里 const a = {}，渲染进程永远拿不到这个 a 的引用。

// 主进程 main.js
const { app, BrowserWindow, ipcMain } = require('electron/main')
const path = require('node:path')

// 主进程里的状态，渲染进程看不到、摸不着
const appState = { counter: 0 }

function createWindow () {
  const win = new BrowserWindow({
    webPreferences: { preload: path.join(__dirname, 'preload.js') }
  })
  win.loadFile('index.html')
}

渲染进程若要读 appState.counter，只能请主进程通过 IPC 把值「发过来」。两边靠消息往来，而非共享内存。

11-3 消息通道是什么

Electron 里的 IPC，是通过「开发者自定义的通道（channel）」传递消息的。你用 ipcMain 和 ipcRenderer 两个模块收发，通道名就是个普通字符串，叫什么都可以。

通道是双向的：同一个名字，主进程能监听、渲染进程也能监听。官方例子里常用带冒号的名字，比如 dialog:openFile，这只是命名习惯，方便阅读，不影响功能。

// 主进程监听 'dialog:openFile' 通道
ipcMain.handle('dialog:openFile', async () => {
  // 真正干活的逻辑放在主进程
  return '选中文件的路径'
})

// 渲染进程（经 preload 暴露）向该通道发请求
// window.electronAPI.openFile() 内部调用 ipcRenderer.invoke('dialog:openFile')

约定俗成的做法是：单向事件用动词短语，请求-响应用 模块:动作 形式。清晰的通道名，能让多窗口、多模块的大项目不至于乱套。

11-4 异步与同步的区别

IPC 有两种常用形态。异步是主流：渲染进程发消息后不等待，主进程处理完通过 Promise 或回调回传。它不阻塞界面，体验顺滑。

同步形态是 ipcRenderer.sendSync，它会卡住整个渲染进程，直到收到回复。官方明确建议避免使用，因为它会阻塞界面、造成卡顿。需要结果时，优先用异步的 invoke。

// 推荐：异步，不阻塞渲染进程
// 渲染进程经 preload 调用
const result = await window.electronAPI.openFile()

// 不推荐：同步，会阻塞渲染进程直到主进程回复
// const result = ipcRenderer.sendSync('synchronous-message', 'ping')

一句话：异步像「发了微信等回复」，同步像「当面堵着人不让走」。界面交互场景，永远选异步。

11-5 为何不能直接共享对象

常有人想：能不能把主进程的一个大对象直接传给渲染进程？答案是不能，也不该。

第一，进程内存不共享，没有「同一个对象」这回事。第二，IPC 传输靠「结构化克隆算法（Structured Clone Algorithm）」，规则和 window.postMessage 完全一致：只认纯数据，比如字符串、数字、布尔、数组、普通对象，以及 Date、Map、Set 这类可克隆内建类型。

要注意原型链不会被带过去。你传一个自定义类的实例，对面收到的是个只剩字段值的普通对象，方法全没了。

还有几类值会直接抛异常，记牢即可：函数、Promise、Symbol、WeakMap、WeakSet。DOM 对象（ImageBitmap、File、DOMMatrix 等）和 Electron 对象（WebContents、BrowserWindow、WebFrame）也一样，因为主进程没有能力解码它们。

// 渲染进程：下面这些都会抛异常
// ipcRenderer.send('bad', document.getElementById('x')) // ❌ DOM 对象
// ipcRenderer.send('bad', () => {})                     // ❌ 函数
// ipcRenderer.send('bad', Promise.resolve(1))           // ❌ Promise

// 正确：只传数据
// ipcRenderer.send('good', { id: 'x', text: 'hello' })  // ✅

所以设计 IPC 时，想清楚「传什么数据」，而不是「传什么对象」。数据的形状要简单、可克隆。

11-6 IPC 与安全的边界

IPC 是能力通道，也是攻击面。渲染进程能发任意 IPC 消息，就等于能指挥主进程做任何事。因此安全模型要求：别把整个 ipcRenderer 暴露给网页，而是用 contextBridge 把它包装成一个个具体函数。

下一章会专门讲 contextBridge 如何安全地「暴露 API」，再后面两章细说 ipcMain 与 ipcRenderer 的收发写法。

本章你只需要记住一个心智模型：IPC 就是跨进程发消息。通道名负责寻址，纯数据是载体，默认走异步。

11-7 通道是事件，可监听可移除

ipcMain 本质上是个 EventEmitter。除了 handle/on，它还提供 once（只监听一次）、off/removeListener（移除某个监听器）、removeAllListeners（清空某通道或全部）。这些在窗口关闭、模块卸载时要做清理，避免监听器越积越多导致内存泄漏。

// 主进程 main.js
ipcMain.once('boot-once', (event, arg) => {
  console.log('这个监听器只会触发一次')
})

// 不再需要时移除
ipcMain.removeListener('set-title', handleSetTitle)
ipcMain.removeAllListeners('set-title')

同理，渲染进程侧的 ipcRenderer 也有 off、removeListener、removeAllListeners、once。当你在组件卸载时取消订阅某个推送通道，应当对应调用移除方法，保持收发两端生命周期一致。

理解「通道即事件」这件事，能帮你把 IPC 当成一套普通的事件系统来设计：注册、触发、清理，三步构成完整闭环，而不只是零散的消息来回。

常见误区

误区一：以为主、渲能共享同一个 JS 对象。两者内存隔离，只能传可克隆的数据。
误区二：为了「拿返回值方便」用 sendSync。它会阻塞渲染进程，应改用 invoke。
误区三：把整个 ipcRenderer 直接交给渲染进程。这是安全红线，请逐接口封装。

小结

IPC 是 Electron 跨进程协作的唯一正道。进程隔离让两边内存不共享，所以通信只能靠发消息。

消息走你自己定义的通道名，内容必须是结构化克隆能处理的纯数据。日常一律用异步，sendSync 留给实在没办法的场合。把这几点吃透，后面学具体 API 会非常轻松。