Electron中IPC渲染进程调用主进程时线程阻塞（误同步非异步）问题

你的代码里出现了本该异步的IPC调用变成同步阻塞的情况，我之前帮朋友排查过类似问题，核心原因主要有两个：

问题根源 #

1. 主线程用了同步文件操作：如果你的copyFile...用的是fs.copyFileSync这类同步API，Electron的主线程会被完全卡住——主线程既要管窗口渲染、IPC通信，又要执行这个同步复制任务，在复制完成前它没法响应任何其他请求，自然导致渲染进程也跟着阻塞。
2. 渲染进程事件监听方式不当：每次调用startCopy都用ipcRenderer.on绑定copy-files-finished事件，会重复绑定多个监听器，不仅可能引发多次回调，还会让你误以为是同步阻塞的问题。

解决方案 #

方案一：用Electron推荐的ipcRenderer.invoke（最简洁） #

这是Electron v7+推出的异步IPC调用方式，内置Promise支持，不用手动管理事件监听，能完美避免阻塞问题。

主线程（Main.js）修改：

const { ipcMain } = require('electron');
const fs = require('fs').promises; // 使用异步版fs API

// 注册可被invoke调用的异步处理方法
ipcMain.handle('copy-files', async (event, data) => {
  try {
    // 替换成你的实际文件复制逻辑，必须用异步方法
    await fs.copyFile(data.sourcePath, data.targetPath);
    return null; // 复制成功返回null
  } catch (error) {
    return error.message; // 复制失败返回错误信息
  }
});

渲染进程（Renderer.js）修改：

export const startCopy = async (data) => {
  try {
    // 用invoke发起异步IPC请求，直接await获取结果
    const error = await ipcRenderer.invoke('copy-files', data);
    return error;
  } catch (ipcError) {
    // 处理IPC通信本身的错误（比如通道不存在等）
    return ipcError.message;
  }
};

方案二：保留原有send/reply模式但修复问题 #

如果你不想改用invoke，可以调整事件监听方式并确保主线程用异步操作：

渲染进程（Renderer.js）修改：

export const startCopy = (data) => {
  return new Promise((resolve, reject) => {
    // 用once替代on，确保每个请求只监听一次完成事件，避免重复绑定
    ipcRenderer.once('copy-files-finished', (event, error) => {
      error ? reject(error) : resolve(null);
    });
    ipcRenderer.send('copy-files', data);
  });
};

主线程（Main.js）修改：

const { ipcMain } = require('electron');
const fs = require('fs').promises;

ipcMain.on('copy-files', async (event, data) => {
  try {
    await fs.copyFile(data.sourcePath, data.targetPath);
    // 用reply给发起请求的渲染进程发送完成信号
    event.reply('copy-files-finished', null);
  } catch (error) {
    event.reply('copy-files-finished', error.message);
  }
});

关键注意点 #

• 绝对不要在Electron主线程里用同步IO操作（比如fs的同步API），主线程一旦阻塞，整个应用的响应都会停滞。
• 渲染进程监听IPC完成事件时，优先用once而不是on，避免多次调用后积累大量无用的监听器。

内容的提问来源于stack exchange，提问作者Goor Lavi