在进程间通信中，除了广泛使用的异步方法，Electron 也提供了一种看似更方便的 同步 IPC —— ipcRenderer.sendSync。它允许渲染进程发送一个消息后原地等待，直到主进程处理完毕并返回结果，就像调用一个普通的同步函数一样。
9.4.1 同步通信的工作方式
同步调用在代码写法上非常简单：
// 渲染进程
const result = ipcRenderer.sendSync('sync-get-data', { id: 42 });
console.log('拿到结果：', result);主进程需要使用 ipcMain.on 来响应这个同步请求，并通过设置 event.returnValue 返回数据：
// 主进程
ipcMain.on('sync-get-data', (event, arg) => {
console.log('收到同步请求，id =', arg.id);
const data = getSomeDataQuickly(arg.id); // 假设这是一个轻量同步操作
event.returnValue = data;
});对于渲染进程而言，sendSync 就像一个普通的函数调用：传入参数，拿回返回值，下一行代码可以立刻使用这个结果。这种“同步思维”与前端常见的 async/await 模型不同，它真正阻塞了 JavaScript 的执行流。
9.4.2 同步通信的代价
同步通信的最大问题在于它会阻塞渲染进程的 JavaScript 执行线程。 在 sendSync 返回之前，整个渲染进程的 UI 线程会被完全冻结：用户点击按钮没有反应，动画停顿，页面像死机一样。如果主进程处理这个请求花费了哪怕几百毫秒，用户都会明显感到界面卡顿。
另一个常被忽视的风险是，一旦主进程的同步处理函数因某些原因未能及时设置 event.returnValue（比如代码逻辑错误、抛出异常被吞掉或陷入死循环），渲染进程将永久挂起，只能通过强制关闭窗口来解决。
此外，同步调用还违反了 Electron 的安全最佳实践。现代 Electron 应用通常采用 contextBridge 暴露经过封装的异步 API，而 sendSync 往往需要直接暴露 ipcRenderer 方法，这会降低安全性。官方文档也明确指出，应尽量避免使用同步 IPC，除非在最极端的启动阶段配置读取等场景。
9.4.3 何时可以使用同步通信？
同步通信并非一无是处，但它的适用范围非常狭窄：
- 应用初始化时的配置读取：启动窗口显示之前，主进程需要读取一个本地的配置文件或环境变量，窗口还未完全展现，阻塞影响极小。
- 轻量的、可靠的同步查询：比如查询当前应用版本号、判断是否开启了某个调试选项，这些操作的执行时间可以忽略不计（微秒级）。
真实项目中更常见的做法是利用 预加载脚本在应用启动阶段一次性批量获取配置，并通过 contextBridge 注入到渲染进程全局，完全避免运行时再去做同步请求。
9.4.4 性能友好的替代方案
绝大多数情况下，用异步 IPC 并配合现代的 async/await 语法，代码清晰度不比同步差，且完全不阻塞 UI：
// 渲染进程
const result = await ipcRenderer.invoke('async-get-data', { id: 42 });
console.log('拿到结果：', result);// 主进程
ipcMain.handle('async-get-data', async (event, arg) => {
const data = await fetchData(arg.id); // 可以是耗时的异步操作
return data;
});invoke/handle 模型基于 Promise，天然支持异步、错误捕获及超时控制，是官方推荐的通信方式。它既保证了界面流畅，又保持了代码的可读性和健壮性。
如果主进程的处理确实很耗时（比如密集计算或批量文件操作），仅仅用异步 IPC 还不够——因为主进程的事件循环也可能被阻塞，导致其他窗口的 IPC 请求无响应。这种场景你需要将重活移到 子进程（child_process） 或 Worker Threads 中执行，然后通过 IPC 与主进程通信，再由主进程将结果转发给渲染进程。这样既解放了 UI 线程，又不会拖累主进程的事件处理。
9.4.5 实际开发中的黄金法则
除非你能 100% 保证操作在 1 毫秒内完成并且调用发生在界面不可见的启动阶段，否则永远使用异步通信。
这一条基本可以覆盖所有业务场景。如果发现现有代码中有 sendSync，请仔细审视：是否真的需要同步？能不能用 invoke/handle 重写？重写过程几乎不会增加工作量的同时，却能消除一个潜在的界面卡顿 bug。
总而言之，同步通信看似便利，实则是性能与稳定性的陷阱。在追求流畅用户体验的前端文化中，异步、非阻塞才是 Electron 进程通信的正确基调。