在这篇文章中，我想聊一聊 Electron 进程间通信（IPC）当前的工作方式，它在设计和实现上存在哪些问题，以及这些问题可以如何被修复和改进。
如果你已经了解 Electron IPC 是什么以及它的工作原理，可以直接跳到 「当前实现的问题」 章节，我在那里描述了一种能够改进它的思路。
什么是 Electron IPC
Electron 基于 Chromium，而 Chromium 采用了多进程架构。应用程序的不同部分运行在不同的进程中，各自负责不同的职责。Electron 应用围绕两类主要的进程类型构建：一个 main（主） 进程和一个或多个 renderer（渲染） 进程。
渲染进程是 Electron 应用加载 HTML、CSS，并在网页中运行 JavaScript 的地方。React、Vue、Svelte 或原生 JavaScript 代码通常都运行在这里。
渲染进程运行在 Chromium 沙箱的隔离环境中。它无法访问本地文件系统，不能启动进程，也不能直接使用其他操作系统能力。这对安全性至关重要，因为外部页面可能包含恶意代码或被污染的依赖。
而在主进程中，你可以管理应用生命周期、创建窗口、与操作系统集成，以及执行渲染进程无法直接完成的特权操作。这通常包括访问 Node.js API、原生对话框、文件系统、进程、菜单、通知、自动更新以及其他桌面相关功能。
你大概已经猜到这会引出什么问题了。Electron 无法把所有逻辑都放在渲染进程里，因为它是隔离的。而运行在渲染进程中的前端，往往需要一些只有主进程才能提供的能力。例如，UI 可能需要读取一个文件、保存用户配置、打开原生对话框、启动后台任务，或者向操作系统查询某些信息。
这正是 Electron 需要 IPC 的原因。它是一座桥梁（继承自 Chromium），连接着运行在渲染进程里的隔离前端，与运行在主进程里的特权后端逻辑。没有 IPC，应用的这两部分就无法协同工作。
Electron IPC 是如何工作的
Electron 中存在几种 IPC 模式：
- Renderer 到 Main（单向）
- Renderer 到 Main（双向）
- Main 到 Renderer（单向）
对日常应用开发来说，最重要的是 Renderer 到 Main（双向） 。当前端需要请求应用的特权侧执行某些操作并等待返回结果时，就会用到这种模式。
根据 Electron 官方文档，实现这种模式的现代做法是使用 ipcRenderer.invoke() 搭配 ipcMain.handle()。实际效果类似于跨进程的请求/响应调用：渲染进程发出请求，主进程处理，结果以 Promise 形式返回。
要让它正常工作，你通常需要三部分代码：
- 主进程中的 handler
- 从 Electron 的
preload脚本暴露出的安全 API - 渲染进程中的调用
让我们看一下 Electron 官方文档中的示例：渲染进程请求主进程打开一个原生的文件选择对话框。
第 1 步：在主进程中注册 handler
在主进程中，定义一个执行特权操作的函数。然后通过 ipcMain.handle() 把这个函数绑定到某个 IPC channel：
const { app, BrowserWindow, dialog, ipcMain } = require('electron')
const path = require('node:path')
async function handleFileOpen() {
const { canceled, filePaths } = await dialog.showOpenDialog({})
if (!canceled) {
return filePaths[0]
}
}
function createWindow() {
const mainWindow = new BrowserWindow({
webPreferences: {
preload: path.join(__dirname, 'preload.js')
}
})
mainWindow.loadFile('index.html')
}
app.whenReady().then(() => {
ipcMain.handle('dialog:openFile', handleFileOpen)
createWindow()
})
在这里，主进程监听 dialog:openFile channel。当该 channel 从渲染进程被调用时，Electron 会执行 handleFileOpen()，等待它完成，并将返回值发回给调用方。
这段代码暴露了 Electron IPC 对开发者而言的一个重要细节：通信是围绕字符串形式的 channel 名称组织的。在本例中，channel 名是 dialog:openFile。前缀 dialog: 只是便于阅读的命名约定，Electron 并不赋予它特殊含义。
第 2 步：通过 preload 暴露受限 API
渲染进程中的 JavaScript 不应该直接调用 Electron 内部实现。推荐的做法是通过 preload 脚本使用 contextBridge 暴露一个窄 API：
const { contextBridge, ipcRenderer } = require('electron')
contextBridge.exposeInMainWorld('electronAPI', {
openFile: () => ipcRenderer.invoke('dialog:openFile')
})
这样一来，渲染进程就能访问 window.electronAPI.openFile()。
这一步非常关键。preload 脚本作为隔离的浏览器环境与 Electron 特权 API 之间的可控边界。Electron 文档明确建议不要把整个 ipcRenderer 对象暴露给渲染进程，这是出于安全考虑。开发者应当手动只暴露允许的那些方法。
第 3 步：在渲染进程中调用 API
现在渲染进程里的前端 JavaScript 可以调用这个 API 并等待结果：
const btn = document.getElementById('btn')
const filePathElement = document.getElementById('filePath')
btn.addEventListener('click', async () => {
const filePath = await window.electronAPI.openFile()
filePathElement.innerText = filePath
})
上面的代码中，按钮被点击时，渲染进程并不会自己打开原生对话框。它调用 window.electronAPI.openFile()，后者通过 ipcRenderer.invoke('dialog:openFile') 转发请求。Electron 随后找到主进程中对应的 ipcMain.handle('dialog:openFile', ...) handler，在那里执行，然后用返回值 resolve 渲染进程中的 Promise。
乍一看，这套模型看起来足够简单。但一旦你的应用规模增长，channel 数量、参数、返回值以及手动暴露的 preload 方法开始增多时，这种设计的弱点就会显露无遗。接下来我们就聊聊，当前 Electron IPC 模型的真正问题。
当前实现的问题
Electron IPC 的一个主要问题是 进程之间缺乏类型安全且透明的 API。开发者必须手动同步主进程与渲染进程之间的契约：
- Channel 名是普通字符串
- 参数通常以任意对象形式传递
- 返回值没有框架层面强制的严格 schema
在一个「Hello, world!」的小应用里，这或许还能接受。但在真实项目中，这就会变成维护上的麻烦。主进程注册了像 dialog:openFile 这样的 handler，preload 脚本为其暴露包装方法，而渲染进程依赖这些包装被正确实现。
Electron 并没有提供一个能把整个 API 作为一致接口来描述的单一事实源（single source of truth）。开发者不得不手动保持几块分散的代码同步。
这会带来几个实际后果：
- 许多错误只能在运行时被发现。 Channel 名拼写错误、参数结构不匹配、缺失字段、返回值异常，这些问题通常在编译期无法被捕获。代码看起来对 TypeScript 没问题，却只在用户触发特定路径时才暴露出来。
- 重构比本应的要难得多。 如果你重命名一个 channel、修改 payload 结构，或把一个 IPC 方法拆成两个，你需要手动更新主进程 handler、
preloadbridge 和每一处渲染进程的调用点。在没有集中式契约的情况下，很容易漏掉其中某个点，从而埋下隐蔽的回归 bug。 - 进程间的 API 不够透明。 打开一个 Electron 代码库，面对一个简单的问题——「当前从 renderer 到 main 实际可用的方法有哪些？」——往往没有明确答案。要搞清楚这个问题，你得在多个文件中搜索
ipcMain.handle()、contextBridge.exposeInMainWorld()和ipcRenderer.invoke()的调用，然后在脑海里重建整个契约。
随着应用规模增长，这通常会演变成一堆散乱的 ipcMain.handle 和 ipcRenderer.invoke 调用，没有集中的 API 描述。结果就是一个比本应更难理解、更难演进、更脆弱的 IPC 层。
换句话说，主要问题并不在于 Electron IPC 无法使用。问题在于它无法很好地扩展。它把过多的手工协调工作留给了开发者，同时提供了过少的保证，让人无法确信应用的两端真的在「说同一种语言」。
Electron IPC 可以如何改进
我认为，如果 Electron IPC 能围绕一个显式契约重新设计，而非依赖临时拼凑的字符串 channel，它的可扩展性会好很多。一种做法是用 Protocol Buffers 来定义渲染进程与主进程之间的接口，为两端生成代码，让开发者针对同一份 API 契约工作，而不是手动协调底层消息传递。
下面展示一下这在实践中可能是什么样子。
契约可以定义在一个 .proto 文件中：
syntax = "proto3";
import "google/protobuf/empty.proto";
import "google/protobuf/wrappers.proto";
service DialogService {
rpc OpenFile(google.protobuf.Empty) returns (google.protobuf.StringValue);
}
这个文件把两件事统一在一个地方描述：
- 进程之间传递的数据的精确结构。
- 生成的 IPC API 所暴露的精确方法集合。
有了它，工具链可以为主进程和渲染进程生成 JavaScript/TypeScript 绑定。这意味着契约不再分散在手写的字符串常量、任意结构的 payload 对象，以及手动同步的包装方法中。它变成了一份正式的 API 定义，配有生成的类型和生成的客户端/服务端 stub。这将提升类型安全性和可发现性，当然，运行时的兼容性仍然依赖于生成的代码、版本管理，以及正确的服务实现。
在主进程中，开发者会像下面这样实现生成的服务方法：
import { dialog, ipcMain } from 'electron';
import { DialogService } from './gen/ipc_service';
ipcMain.registerService(DialogService({
async OpenFile() {
const { canceled, filePaths } = await dialog.showOpenDialog({})
return { value: canceled ? '' : filePaths[0] }
}
}))
而在渲染进程中，这份契约会作为一个带类型的异步 API 被使用：
import { ipcRenderer } from './gen/ipc';
ipcRenderer.dialog.OpenFile({}).then((filePath) => {
console.log(filePath.value)
})
在底层，Electron 仍然可以沿用其现有的 IPC 传输机制。改进发生在 API 设计层：开发者不再直接与原始 channel 名和手动构造的 payload 打交道，而是 使用由单一契约派生出来的、RPC 风格的生成接口。
这种做法在几个方面都能解决当前 Electron IPC 的问题：
- 引入单一事实源。 渲染进程与主进程之间的 API 存在于
.proto定义中，而不是散落在各处的 handler 注册和 preload 包装里。想知道存在哪些 IPC 方法，看服务定义即可。 - 让 IPC 层具备类型安全。 请求和响应的结构被显式定义，生成为 TypeScript 类型，并在编译期进行检查。许多目前只能在运行时发现的错误，可以被提前捕获。
- 让重构安全得多。 重命名方法、修改 payload 或更新返回类型都从契约开始，生成的代码会立刻告诉你应用中还有哪些地方需要跟进修改。
- 让 IPC API 更透明、更具可扩展性。 应用拥有一组结构化的服务和方法，而不是一堆互不关联、不断增长的 channel 字符串集合。代码规模扩大后，也更容易理解。
- 减少开发者手写的重复样板代码。 大量胶水代码可以自动从契约生成，无需为每个 IPC 方法手动创建并维护一个自定义包装。
总结
这种做法最大的优势是一个 契约优先、代码生成、RPC 风格 的模型，让应用两端更容易保持同步。它会让 Electron IPC 更可预测、更易于维护，也更适合大型应用。
希望这个思路能被 Electron 团队采纳，或至少在社区中被讨论。
参考链接
- Electron IPC 官方文档： www.electronjs.org/docs/latest…
- Protocol Buffers： protobuf.dev/
