9.2 异步双向通信：invoke /handle 请求响应模式

在 9.1 节你已经知道，Electron 的进程间通信（IPC）是主进程与渲染进程协作的桥梁。send 和 on 虽然能实现消息传递，但它们本质上是“单向通知”：渲染进程可以“喊一声”告诉主进程去做某件事，但很难优雅地拿到主进程返回的结果。你不得不额外再建一条通道让主进程“喊回来”，代码很快就会变得凌乱。

Electron 从 7.0 版本开始提供了 ipcRenderer.invoke + ipcMain.handle 这对 API，专门解决“渲染进程调用主进程方法并获取返回值”的场景。你可以把它理解成一个跨进程的异步函数调用：渲染进程像调用本地 Promise 一样发起请求，主进程处理完毕后返回结果，全程代码清晰可读。

9.2.1 从回调地狱到清晰的异步调用

假设你需要让渲染进程读取一个本地文件的内容，然后用这个内容更新 UI。如果用 send / on 模式，你会这么写：

// 渲染进程
ipcRenderer.send('read-file', '/path/to/file.txt');
ipcRenderer.on('read-file-reply', (event, data) => {
  // 拿到数据，更新界面
});

// 主进程
ipcMain.on('read-file', (event, filePath) => {
  const data = fs.readFileSync(filePath, 'utf-8');
  event.reply('read-file-reply', data); // 或者 event.sender.send
});

这样一个简单的“读文件并返回”就需要在两个进程中各写一个监听，而且代码不是线性的：发送请求和接收回复被硬生生拆到了两个地方，逻辑稍复杂就会陷入“回调套回调”的泥潭。

而用 invoke / handle 模式，同样的需求可以写成：

// 主进程
ipcMain.handle('read-file', async (event, filePath) => {
  const data = await fs.promises.readFile(filePath, 'utf-8');
  return data;
});

// 渲染进程（通过预加载脚本暴露的 API 调用）
const data = await window.api.invoke('read-file', '/path/to/file.txt');
// 直接拿到 data，更新 UI

整个流程变成一条直线：发起请求 → 等待结果 → 拿到返回，就像调用了一个异步本地函数。这就是 invoke / handle 最本质的价值：把跨进程调用还原为自然的请求-响应模型。

9.2.2 核心 API 用法

主进程：`ipcMain.handle(channel, handler)`

在 channel 上注册一个处理器函数。每当有渲染进程通过 invoke 调用这个频道时，该函数就会被执行。处理器可以返回一个值（或一个 Promise），这个值（或 Promise 决议的结果）会自动送回渲染进程。

// 预加载脚本或主进程文件中
const { ipcMain } = require('electron');

ipcMain.handle('get-user-info', async (event, userId) => {
  // event 对象可以获取发送请求的窗口信息，通常做权限检查
  const user = await database.findUserById(userId);
  return user; // 可以直接返回对象，会自动序列化
});

说明：

handler 的第一个参数是 event，包含请求来源（如 event.sender），你可以用它来判断是哪个窗口发起的请求。
后续参数就是 invoke 传递过来的参数，按顺序对齐。
处理器可以是同步或异步，推荐始终使用 async 或返回 Promise，因为调用的性质就是异步的。

渲染进程：`ipcRenderer.invoke(channel, ...args)`

返回一个 Promise，该 Promise 会在主进程处理器完成并返回结果后变为 resolved。如果主进程处理器抛出错误（或 Promise 变为 rejected），这个 Promise 也会被 reject。

// 预加载脚本中暴露给渲染进程
const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('api', {
  invoke: (channel, ...args) => ipcRenderer.invoke(channel, ...args),
});

然后在渲染进程里使用：

// 渲染进程
async function loadUser(id) {
  try {
    const user = await window.api.invoke('get-user-info', id);
    console.log(user);
  } catch (error) {
    console.error('获取用户失败', error);
  }
}

9.2.3 请求-响应模式的典型场景

invoke / handle 特别适合所有“问主进程拿数据或执行操作并返回结果”的情况：

文件操作：打开文件对话框选择路径、读取/写入文件、获取文件属性。
访问系统目录：获取用户文档目录、临时目录、应用数据目录。
调用 Node.js 原生模块：如 crypto、dns、child_process 等，渲染进程不直接访问 Node 环境时，通过主进程转发。
操作数据库：所有本地数据库（SQLite、LevelDB）的增删改查请求。
获取应用配置：主进程保存的应用宽高、语言、主题等设置。

以最常见的“打开文件”为例：

// 主进程
ipcMain.handle('dialog:openFile', async () => {
  const { canceled, filePaths } = await dialog.showOpenDialog({
    properties: ['openFile'],
    filters: [{ name: 'Markdown', extensions: ['md'] }],
  });
  if (canceled) return null;
  return filePaths[0];
});

// 渲染进程调用
const filePath = await window.api.invoke('dialog:openFile');
if (filePath) {
  // 处理文件路径
}

整个过程渲染进程不需要知道 dialog 模块的存在，也不需要担心安全风险——主进程就像一个受控的 API 服务端，暴露有限的能力给前端界面。

9.2.4 错误处理与多通道管理

由于 invoke 返回的是一个标准 Promise，你可以用 try/catch 或者 Promise.catch 来捕获主进程执行中的异常，这比监听错误消息事件要自然得多。

// 主进程处理器内抛出的错误会自动传递到渲染进程
ipcMain.handle('dangerous-task', async () => {
  throw new Error('文件损坏，无法继续');
});

// 渲染进程
try {
  await window.api.invoke('dangerous-task');
} catch (err) {
  console.error('任务失败:', err.message);
}

如果你的应用需要注册多个处理器，可以给每个功能分配不同的频道名称（字符串）。常见的做法是使用命名空间管理的命名模式，如 'dialog:openFile'、'db:getNote'、'config:getTheme'，避免频道名称冲突。

9.2.5 安全性提醒

在 9.1 节我们已经强调了上下文隔离（contextIsolation: true）的重要性。使用 invoke / handle 时，绝对不要直接在渲染进程中访问 ipcRenderer，必须通过预加载脚本使用 contextBridge 暴露一个安全的 API 包装。这样做可以避免网页内容直接获取到整个 ipcRenderer 对象，从而防止恶意脚本调用任意频道。

// ❌ 危险：直接将 ipcRenderer 暴露到全局
contextBridge.exposeInMainWorld('ipcRenderer', ipcRenderer);

// ✅ 正确：只暴露需要的 invoke 方法
contextBridge.exposeInMainWorld('api', {
  invoke: (channel, ...args) => ipcRenderer.invoke(channel, ...args),
});

更进一步，你还可以在暴露的 invoke 方法中加入频道白名单校验，防止渲染进程随意调用主进程未预期的频道（比如只允许以 'public:' 开头的频道），不过这已经属于进阶安全实践。

9.2.6 与旧版 send / on 的对比及迁移建议

| 特性 | send / on 模式 | invoke / handle 模式 |
|---|---|---|
| 代码清晰度 | 需要双向监听，逻辑分散 | 线性异步调用，结构清晰 |
| 返回值获取 | 需要自定义回复频道 | 返回 Promise 直接拿到结果 |
| 错误处理 | 需要额外定义错误事件 | Promise 的 catch 直接捕获 |
| 多参数传递 | 通过数组或对象 | 按参数顺序传递，自然串联 |
| 使用场景 | 仍需单向通知，如事件广播 | 所有请求-响应场景 |

对于大多数新项目，Electron 官方推荐使用 invoke / handle 来处理渲染进程向主进程的请求。单向通知类（例如“主进程通知渲染进程某个状态变化”）仍然可以用 webContents.send 和 ipcRenderer.on，但这两者的分工已经很明确：主进程通知渲染进程用 send，渲染进程请求主进程用 invoke。

9.2.7 常见误区与注意点

不要用 invoke 来处理持续的数据流

invoke 设计为一次请求一次响应。如果你需要持续不断地从主进程推送数据（比如实时日志、文件监控变化），应该改用 webContents.send 配合事件监听，否则每次都要重新发起调用，浪费且不合理。

不要在主进程处理器中同步循环阻塞

handle 回调默认在调用它的渲染进程的对应事件循环中执行，虽然它是一个异步函数，但也应避免长时间同步循环阻塞。长时间任务应当异步化，或者使用 child_process / worker 来处理。

返回值序列化限制

主进程返回的结果会通过结构化克隆算法（Structured Clone）进行序列化，因此可以安全传递大多数 JavaScript 内置类型（对象、数组、日期、Map、Set、Buffer 等）。但无法传递函数、DOM 元素或循环引用的对象。如果需要，可以考虑将数据处理在主进程完成，仅返回纯数据。

一个频道多次调用 handle？

如果你为一个频道注册了多个处理器，只有最后一个注册的会生效。这与事件监听器不同，handle 是覆盖式注册。如果需要动态卸载，可以使用 ipcMain.removeHandler(channel)。

9.2.8 小结

invoke / handle 是 Electron 进程间通信的一次重要进化。它让渲染进程和主进程之间的函数调用变得像本地异步函数调用一样简单，大大降低了代码的心智负担。在实际项目中，几乎所有的“渲染进程问主进程要数据或做事”都应采用这种模式。配合预加载脚本的安全封装，你可以在保持应用架构清晰的同时，确保安全性不受破坏。熟练掌握这一模式，是你构建复杂桌面应用的基础技能。