4.3 通信模式原理 - 人人都会AI编程

理解了主进程与渲染进程的分工之后，下一个核心问题就是：它们之间如何对话？这一节不会罗列 API 文档，而是从“为什么要这样设计”出发，帮助你建立起对 Electron 通信模型的直觉。

4.3.1 为什么需要进程间通信

Electron 的多进程架构带来稳定性和安全性，但也制造了一道天然的屏障：渲染进程不能直接调用 Node.js 或 Electron 的原生 API（在 contextIsolation: true 的默认配置下）。当用户在界面上点击“保存文件”按钮时，实际上会发生这样一串动作：

渲染进程（网页环境）捕获点击事件。
渲染进程不能自己调用 fs.writeFile，因为它的运行环境是一个受限的浏览器沙箱。
渲染进程必须把“我想保存文件”这个意图发送给主进程。
主进程（拥有完整系统权限）收到消息后，调用 Node.js 的 fs 模块完成文件写入，然后把结果返回给渲染进程。
渲染进程更新界面，告知用户保存成功。

这个过程就是进程间通信（IPC, Inter-Process Communication）。它是 Electron 应用的“神经系统”，所有跨进程的安全操作都依赖它来完成。

4.3.2 通信的两种基本模式

Electron 提供了两套并行的 IPC 原语，分别对应两种最常见的通信需求：

模式一：异步消息传递（fire-and-forget 与事件监听）

使用 ipcRenderer.send 和 ipcMain.on，这是一种单向的、异步的消息推送。渲染进程向主进程发送一个消息，不期待返回值（或者通过另一个通道接收结果）。

渲染进程代码（通过预加载脚本暴露的 API 调用）：

// 发送消息，不期待返回值
window.electronAPI.sendMessage('save-file', { path: '/doc.txt', content: 'Hello' });

主进程代码：

const { ipcMain } = require('electron');

ipcMain.on('save-file', (event, data) => {
  // data 就是渲染进程传过来的 { path, content }
  fs.writeFileSync(data.path, data.content);
  // 如果有需要，可以通过 event.sender 再发一个消息回渲染进程
  event.sender.send('save-file-result', { success: true });
});

这种模式适合那些“发起一个动作就完事”的场景，比如窗口最小化、触发后台任务。如果需要传回结果，就需要像上面那样再反向发送一个消息（渲染进程用 ipcRenderer.on 监听）。

模式二：请求-响应模式（invoke / handle）

如果你更习惯 fetch 那种“发请求、拿结果”的思维，Electron 提供了基于 Promise 的 ipcRenderer.invoke 和 ipcMain.handle。这是一种双向的、带返回值的异步通信。

渲染进程：

const result = await window.electronAPI.saveFile({ path: '/doc.txt', content: 'Hello' });
console.log(result); // { success: true }

主进程：

ipcMain.handle('save-file', async (event, data) => {
  await fs.promises.writeFile(data.path, data.content);
  return { success: true };
});

invoke / handle 模式的优点是：

代码更加线性、易读，避免了回调地狱。
返回值可以直接用 await 获取，不需要手动监听反向事件。
错误处理更自然，主进程抛出异常会被渲染进程的 Promise 捕获。

在现代 Electron 开发中，对于需要返回结果的通信，官方推荐优先使用这种模式。

4.3.3 通信的中介：预加载脚本与 contextBridge

渲染进程代码通常写在网页中，而主进程代码在 Node.js 环境。如果直接把 ipcRenderer 暴露给网页，意味着任何被注入的第三方脚本也可以随意调用 IPC，这相当于开了一个巨大的安全后门。

Electron 的解决方案是 预加载脚本（preload.js） + contextBridge。预加载脚本是一个在渲染进程的网页加载之前运行的 JS 文件，它可以访问 Node.js 和 Electron 的 API。通过 contextBridge.exposeInMainWorld，可以精确地选择哪些函数暴露给网页环境。

典型的预加载脚本结构：

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('electronAPI', {
  // 暴露一个 async 函数，内部调用 ipcRenderer.invoke
  saveFile: (data) => ipcRenderer.invoke('save-file', data),
  // 暴露一个监听函数
  onFileSaved: (callback) => {
    ipcRenderer.on('file-saved', (event, result) => callback(result));
  },
  // 移除监听，避免内存泄漏
  removeFileSavedListener: () => {
    ipcRenderer.removeAllListeners('file-saved');
  }
});

网页中就可以安全地使用 window.electronAPI.saveFile(…)，而无法直接接触到 ipcRenderer 对象。这种经过筛选的桥接层，既保证了功能的可用性，也把攻击面降到了最小。实战中，所有需要调用主进程能力的操作，都应该通过预加载脚本集中管理，而不是在每个页面里散落一堆 require('electron')。

4.3.4 同步通信的陷阱（尽量避免）

Electron 也支持通过 ipcRenderer.sendSync 发送同步消息，主进程用 ipcMain.on 直接返回结果。这种调用会阻塞渲染进程，直到主进程完成操作才恢复 UI。

// 不推荐的写法
const result = ipcRenderer.sendSync('get-data-sync');

除非是非常轻量的简单取值（例如获取一个配置常数），否则应当严格避免同步 IPC。原因有二：

如果主进程处理消息时耗时较长（例如读取大文件），整个窗口的 UI 会卡死，用户无法进行任何交互。
同步调用会让程序逻辑变得脆弱，难以维护和扩展。

现代 Electron 应用几乎已经全面转向异步通信。同步 API 的存在更多是为了历史兼容，新项目除非有绝对充分的理由，否则不要使用。

4.3.5 实际通信流程拆解

为了让你对这种模式有更具体的体感，我们以“打开文件对话框并读取内容”为例，把整个通信过程串起来：

渲染进程：用户点击“打开文件”按钮，调用 window.electronAPI.openFile()。
预加载脚本：该函数内部执行 ipcRenderer.invoke('dialog:openFile')。
消息传输：IPC 消息通过 Chromium 的内核管道发送到主进程。
主进程：ipcMain.handle('dialog:openFile', …) 收到调用，依次执行：

dialog.showOpenDialog(win, options) 弹出系统原生文件选择框。
用户选择文件后，获取文件路径。
使用 fs.readFile 读取文件内容。
返回 { filePath, content } 给渲染进程。

Promise 完成：渲染进程的 openFile() 得到结果，更新界面显示文件内容。

整个过程只有消息在传递，渲染进程从未接触到文件系统，系统对话框也是由主进程代理调用的。这就是“安全隔离，按需暴露”的实践体现。

4.3.6 主进程到渲染进程的通信

前面讲的都是渲染进程主动发起通信，但主进程有时也需要主动向渲染进程推送消息，例如：

应用即将关闭，提醒用户保存数据。
系统主题发生了变化（深色/浅色模式）。
其他窗口触发的全局状态更新。

主进程可以通过 BrowserWindow.webContents.send 向指定窗口的渲染进程发送消息：

主进程：

mainWindow.webContents.send('theme-changed', 'dark');

预加载脚本暴露监听器，网页中调用：

window.electronAPI.onThemeChanged((theme) => {
  // 更新界面主题
});

在实际项目中，这种通信通道通常会用在全局事件总线上，让不同窗口之间也能通过主进程作为中转站来交换信息。

理解了上述原理，你在阅读官方文档或别人的代码时，就能迅速识别出通信模式，并知道应该选用 send/on 还是 invoke/handle。在接下来的章节中，我们会将这些原理应用到真实的业务场景中，并展示如何组织这些通道代码，让项目结构保持清晰可维护。