一次搞定IPC通信的坑与实战技巧

直接上手：Electron里的IPC通信就这么玩

我最近在做一个桌面端应用，用 Electron 开发的。需求很简单：主进程监控某个系统事件（比如 USB 插拔），然后把结果实时推给渲染进程展示。听起来简单吧？但刚上手的时候，IPC 这块真给我整迷糊了。

今天不说概念，先贴代码。你要是也在搞 Electron，想让主进程和页面之间传数据，下面这些方式亲测有效。

// preload.js
const { contextBridge, ipcRenderer } = require('electron')

contextBridge.exposeInMainWorld('electronAPI', {
  onUsbChange: (callback) => ipcRenderer.on('usb-change', (_event, info) => callback(info)),
  requestDeviceInfo: () => ipcRenderer.send('get-device-info')
})

// renderer.js （页面中）
window.electronAPI.requestDeviceInfo()

window.electronAPI.onUsbChange((info) => {
  console.log('设备变化:', info)
  // 更新UI
})

// main.js
const { ipcMain } = require('electron')

// 模拟设备状态变化
setInterval(() => {
  mainWindow.webContents.send('usb-change', {
    action: 'connected',
    device: 'USB Drive',
    time: new Date().toISOString()
  })
}, 5000)

ipcMain.on('get-device-info', (event) => {
  event.reply('device-info-response', { os: process.platform, uptime: process.uptime() })
})

看到没？核心就三步：

• 预加载脚本暴露 API 给渲染进程
• 主进程通过 webContents.send 主动推消息
• 渲染进程用 ipcRenderer.on 监听

别一上来就研究什么同步异步、双向通信，先把上面这套跑通再说。我第一次写的时候非要用 invoke 和 handle，折腾了半天发现回调不触发——后来才知道是因为没有正确 return 值。

这个场景最好用：主进程主动通知

有些数据不是“请求-响应”模式，而是“有事你就喊我”。比如日志监听、硬件状态、后台任务进度。

这时候千万别让渲染进程轮询！太 low 也太耗资源。正确的做法是主进程 detect 到变化后直接广播。

// main.js
function setupFileWatch() {
  const watcher = require('chokidar').watch('/path/to/logs')
  watcher.on('change', (path) => {
    if (mainWindow && !mainWindow.isDestroyed()) {
      mainWindow.webContents.send('log-file-changed', { path, timestamp: Date.now() })
    }
  })
}

// renderer.js
window.electronAPI.onLogFileChanged((data) => {
  fetchLogContent(data.path).then(content => {
    updateLogViewer(content)
  })
})

这里注意下，我踩过坑：如果窗口被关了你还 send，会报错。所以每次 send 前加个 if (mainWindow && !mainWindow.isDestroyed()) 很必要。

另外，多个渲染窗口怎么办？比如你开了两个窗口，都得收到消息。那就得遍历所有窗口：

BrowserWindow.getAllWindows().forEach(win => {
  if (!win.isDestroyed()) {
    win.webContents.send('some-global-event', data)
  }
})

异步请求怎么搞？别乱用 send

之前有个同事非要用 send + on 实现异步请求，搞得回调嵌套一堆，还容易漏掉响应。后来我们统一改成 invoke/handle 模式。

// preload.js
contextBridge.exposeInMainWorld('electronAPI', {
  getSystemInfo: () => ipcRenderer.invoke('get-system-info'),
  saveConfig: (config) => ipcRenderer.invoke('save-config', config)
})

// main.js
ipcMain.handle('get-system-info', async () => {
  return {
    platform: process.platform,
    arch: process.arch,
    memory: (await import('os')).totalmem()
  }
})

ipcMain.handle('save-config', async (event, config) => {
  await fs.promises.writeFile('./config.json', JSON.stringify(config))
  return { success: true }
})

// renderer.js
async function loadInfo() {
  const info = await window.electronAPI.getSystemInfo()
  displaySystemInfo(info)
}

这种模式的好处是：像调函数一样自然，支持 Promise，错误也能被捕获。不过要注意，handle 必须 return 或 throw，否则页面那边会一直 pending。

还有个坑：传递的数据必须能被 structured clone algorithm 处理。别传函数、DOM 节点或者 EventEmitter 实例，一定会崩。

踩坑提醒：这三点一定注意

说说我翻过的几个大跟头：

• 内存泄漏：监听事件没移除。尤其是页面可能频繁打开关闭的情况下，记得解绑：

// renderer.js
const handleUsbChange = (info) => { /* ... */ }
window.electronAPI.onUsbChange(handleUsbChange)

// 页面销毁前
window.addEventListener('beforeunload', () => {
  ipcRenderer.off('usb-change', handleUsbChange)
})

• 安全问题：别直接 expose 整个 ipcRenderer。我见过有人这么干：

// ❌ 千万别这么写！
contextBridge.exposeInMainWorld('electron', { ipc: ipcRenderer })

这就等于把大门钥匙扔街上，恶意页面可以随便发 IPC 消息。一定要封装成明确的方法名，做白名单控制。

• 跨域风格拦截：Electron 的 CSP 策略可能会拦掉内联脚本。如果你在 preload 里用了 require，但没配对上下文隔离和 nodeIntegration，就会报错。我的配置长这样：

// main.js
new BrowserWindow({
  webPreferences: {
    preload: path.join(__dirname, 'preload.js'),
    contextIsolation: true,
    nodeIntegration: false
  }
})

配合 contextBridge 使用，这才是官方推荐的安全模式。

高级技巧：仿造 RPC 调用

项目做大了以后，我们搞了个小工具，让主进程的方法能像远程接口一样调。

// utils/ipcClient.js
class IpcClient {
  constructor(namespace) {
    this.namespace = namespace
  }

  async call(method, ...args) {
    const channel = ${this.namespace}.${method}
    return await ipcRenderer.invoke(channel, ...args)
  }
}

// preload.js
contextBridge.exposeInMainWorld('api', {
  system: new IpcClient('system'),
  config: new IpcClient('config')
})

// main.js
class IpcServer {
  constructor(namespace, handlers) {
    Object.keys(handlers).forEach(method => {
      const channel = ${namespace}.${method}
      ipcMain.handle(channel, handlers[method])
    })
  }
}

new IpcServer('system', {
  getInfo: () => ({ version: app.getVersion() }),
  reboot: () => app.relaunch()
})

// renderer.js
window.api.system.call('getInfo').then(info => console.log(info))

虽然看起来有点重，但在多人协作的大项目里特别有用。接口清晰，不怕冲突，还能加中间件做日志、限流。

性能实测：高频通信怎么办

有一次我们要传摄像头帧数据，每秒30次，刚开始用 IPC 直接传 base64 图片，CPU 直接飙到80%+。后来改用共享内存+文件路径传递，才压下来。

结论是：IPC 不适合传大体积数据。如果是大量数据传输，建议走 HTTP 本地服务或者临时文件中转。

// bad: 传大图
mainWindow.webContents.send('frame-update', { image: largeBase64String })

// good: 传文件名
mainWindow.webContents.send('frame-update', { path: '/tmp/frame-123.jpg' })
// 页面里用 <img src="file:///tmp/frame-123.jpg">

当然要处理好路径权限问题，macOS 上沙盒模式可能读不了任意路径。这块我们最后是用了 app.getPath('temp') 来统一管理。

结尾碎碎念

以上是我踩坑后的总结，希望对你有帮助。IPC 看似简单，但真正在复杂应用里用起来，细节特别多。安全、性能、内存、错误处理，哪一块没做好都能让你半夜被报警叫醒。

这个技巧的拓展用法还有很多，比如多窗口通信、插件系统消息总线、调试面板联动等，后续会继续分享这类博客。

有更优的实现方式欢迎评论区交流。我现在只想去喝杯咖啡，刚刚修完一个因为 IPC 事件重复绑定导致的 UI 卡死 bug……