在 Electron 应用里，你写的每一行界面代码都运行在一个独立的渲染进程中，而操作系统的“特权操作”——比如读写文件、显示系统对话框、创建托盘——则必须由主进程来完成。这两个进程的地址空间彼此完全隔离：渲染进程看不到主进程的变量，主进程也访问不到渲染进程的 DOM。想让它们协作，就必须有一种可靠的方式来回传递消息。IPC（Inter-Process Communication，进程间通信）就是 Electron 为此设计的桥梁。
4.1.1 为什么需要 IPC
安全与稳定是首要原因。从 Electron 12 开始，官方强烈建议开启 contextIsolation: true，这意味着渲染进程不再能直接接触到 Node.js 或 Electron 的原生模块。你的前端代码就像一个普通网页，它唯一能做的就是拿到 preload.ts 暴露给它的一小撮“安全函数”。这些函数背地里通过 IPC 把请求发给主进程，由主进程在权限受控的环境下完成实际操作。
这样做的好处非常现实：
- 即使页面被人注入了恶意脚本，攻击者也无法直接调用
require('fs')去偷用户文件，因为渲染进程本身根本没有访问fs的权限。 - 一个渲染进程崩溃（比如因为内存泄漏或死循环）不会影响主进程和其他窗口，因为它们在操作系统层面就是独立的进程。
从工程角度看，明确的通信边界也倒逼出更清晰的架构。主进程专注于应用生命周期、系统交互和后台任务；渲染进程则只处理界面、动画和用户交互。两者像前端和后端一样，通过“API 调用”的方式协作，职责分明。
4.1.2 通信是如何工作的
Electron 的 IPC 底层基于 Chromium 的 Channel 机制，但对开发者来说，它被封装成了两个简单直接的模块：
ipcMain（主进程端）
用来监听来自渲染进程的消息，并向渲染进程回复。
ipcRenderer（渲染进程端）
用来向主进程发送消息，并接收主进程的回复。
一个典型的“双向应答”流程像用 HTTP 请求一样自然：渲染进程发出一个带参数的请求并等待结果，主进程处理完业务后把数据返回。代码层面就是：
// 预加载脚本 (preload.ts)
import { contextBridge, ipcRenderer } from 'electron';
contextBridge.exposeInMainWorld('myAPI', {
openFileDialog: () => ipcRenderer.invoke('dialog:openFile'),
});// 主进程 (main.ts)
import { ipcMain, dialog } from 'electron';
ipcMain.handle('dialog:openFile', async () => {
const result = await dialog.showOpenDialog({ properties: ['openFile'] });
return result.filePaths;
});在渲染进程里（比如 Vue 组件中），你只需要调用 window.myAPI.openFileDialog()，就像调用一个普通的异步函数，然后拿到用户选择的文件路径。整个过程对前端开发者完全透明——他们不需要理解进程间管道怎么建立、数据怎么序列化，只需要收发 Promise。
4.1.3 消息的传递与序列化
当渲染进程调用 ipcRenderer.invoke 时，你传进去的参数（字符串、数字、对象、数组等）会被 Electron 自动使用结构化克隆算法进行深拷贝，再传给主进程。返回的结果同样会被深拷贝后送回渲染进程。
这里有两个实践要点一定要记住：
- 不是引用传递，而是值复制。你在渲染进程里修改接收到的数据，不会影响主进程那边的对象，反之亦然。这个特性避免了并发修改带来的诡异 bug，但也意味着大体积对象（如上万条数据）的频繁传递会有一定性能开销。
- 函数、DOM 元素、WeakMap 等复杂对象无法被序列化。如果你试图传递一个包含方法的对象，Electron 会直接抛出异常。如果需要调用主进程里的某段逻辑，正确的做法永远是定义好通信通道，在渲染进程侧发消息过去触发。
Electron 的 IPC 还支持更简单的单向消息（ipcRenderer.send + ipcMain.on），以及主进程主动向渲染进程推送消息（webContents.send）。这些模式完全覆盖了通知、状态同步、进度上报等常见场景。
4.1.4 安全的命门：contextBridge
刚才的例子里，我们没有直接在渲染进程中使用 ipcRenderer，而是把它藏在 preload.ts 中，通过 contextBridge.exposeInMainWorld 有选择地暴露给前端。这是现代 Electron 开发中不可妥协的安全底线。
早期 Electron 允许在渲染进程里直接 require('electron') 调用所有 API，但那种模式会让任何一个 XSS 漏洞变成灾难。如今，contextBridge 像是主进程和渲染进程之间的“海关”：你只能通过它预先声明的那几个接口与主进程对话。凡是没暴露的 API（比如 ipcRenderer.send 本身），渲染进程代码就直接找不到。
这也意味着，你在设计 IPC 通道时，应当遵循最小权限原则：只暴露每个窗口真正需要的那些功能。如果一个窗口仅仅是展示用户协议，它就不应该能调用“删除用户数据”的主进程接口。
总结一下，Electron 的 IPC 通信本质上是一套经过安全封装的异步消息管道。它把“危险的系统能力”锁在主进程里，把“好看的界面”放在渲染进程里，中间用结构化的 Promise 调用连接起来。理解并正确使用这套机制，是写出既安全又健壮的 Electron 应用的核心所在。