Electron作为目前最主流的JavaScript桌面应用开发框架，其架构设计决定了它天然采用多进程模型。主进程负责创建窗口、管理应用生命周期、访问操作系统底层能力；渲染进程则负责展示界面，本质上是运行在Chromium中的网页。这两个进程相互隔离，不能直接访问对方的变量和方法，所有数据交换都必须依赖进程间通信（IPC）机制。理解并熟练运用这套通信体系，是开发稳定桌面应用的基础。
一、理解Electron的进程模型与通信基础
在动手写代码之前，需要先弄清楚为什么要有两套进程。主进程是应用的入口，运行package.json中main字段指定的脚本，它拥有完整的Node.js环境，可以调用fs、path等模块读写文件、操作注册表、创建系统托盘。而每一个BrowserWindow实例都会启动一个独立的渲染进程，这个进程默认只有浏览器环境，用来渲染HTML页面。
这种隔离设计有两个重要目的。第一是安全：网页内容天然不可信，如果渲染进程直接拥有Node能力，一旦页面被注入恶意脚本，攻击者就能通过require('child_process')执行系统命令，后果不堪设想。第二是稳定：某个页面崩溃只会影响对应的渲染进程，主进程和其他窗口不受影响。因此从Electron 12开始，nodeIntegration默认关闭，contextIsolation默认开启，通信必须走规范化的IPC通道。
Electron提供的通信模块是一对搭档：主进程使用ipcMain监听和响应消息，渲染进程使用ipcRenderer发送消息。在开启上下文隔离的场景下，还需要借助contextBridge把安全的接口暴露给页面。三者配合，构成了现代Electron应用的通信骨架。
二、基础通信方式：send与on的经典组合
最基础的通信模式是单向消息传递。渲染进程通过ipcRenderer.send发送消息，主进程通过ipcMain.on接收。下面是一个完整的示例，演示点击按钮后主进程读取配置文件并弹出系统对话框。
先看主进程的代码，文件名为main.js：
const { app, BrowserWindow, ipcMain, dialog } = require('electron')
const path = require('path')
let mainWindow = null
function createWindow() {
mainWindow = new BrowserWindow({
width: 1000,
height: 700,
webPreferences: {
preload: path.join(__dirname, 'preload.js'),
contextIsolation: true,
nodeIntegration: false
}
})
mainWindow.loadFile('index.html')
}
// 监听渲染进程发来的消息
ipcMain.on('open-file-dialog', (event, arg) => {
console.log('收到渲染进程消息：', arg)
dialog.showOpenDialog(mainWindow, {
properties: ['openFile']
}).then(result => {
if (!result.canceled && result.filePaths.length > 0) {
// 通过event.sender向发送方回复消息
event.sender.send('file-selected', result.filePaths[0])
}
})
})
app.whenReady().then(createWindow)由于上下文隔离已开启，页面脚本不能直接使用ipcRenderer，需要通过preload脚本做桥接。preload脚本在一个特殊环境中运行，既能访问部分Electron API，又与页面上下文隔离。新建preload.js文件：
const { contextBridge, ipcRenderer } = require('electron')
// 只暴露需要的方法，避免把整个ipcRenderer直接交给页面
contextBridge.exposeInMainWorld('electronAPI', {
openFileDialog: (msg) => ipcRenderer.invoke('open-file-dialog', msg),
onFileSelected: (callback) => {
// 移除旧监听，防止重复注册导致回调执行多次
ipcRenderer.removeAllListeners('file-selected')
ipcRenderer.on('file-selected', (event, filePath) => callback(filePath))
}
})页面脚本调用方式非常简洁，index.html中的代码如下：
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<button id="btn">选择文件</button>
<script>
const btn = document.getElementById('btn')
btn.addEventListener('click', async () => {
// 调用preload暴露的接口，发送IPC消息
await window.electronAPI.openFileDialog('请选择一个文件')
})
// 监听主进程的回复
window.electronAPI.onFileSelected((filePath) => {
alert('你选择了：' + filePath)
})
</script>
</body>
</html>这套模式的关键点在于contextBridge.exposeInMainWorld，它把一个白名单形式的API对象挂载到window上，页面只能调用暴露出来的方法，无法触及内部实现。相比直接把ipcRenderer整个暴露出去，这种做法把攻击面压缩到了最小。同时要注意监听器的重复注册问题，如果页面会多次调用onFileSelected，务必先移除旧监听，否则回调会被执行多次，这是实际项目中最常见的坑之一。
三、异步请求模式：invoke与handle的进阶用法
send与on的组合适合事件通知类场景，但存在一个明显缺陷：渲染进程发出消息后无法直接拿到返回值，只能靠主进程再发一条消息回来，代码被拆成两半，逻辑割裂。Electron 7引入的ipcRenderer.invoke和ipcMain.handle解决了这个问题，它返回一个Promise，让跨进程调用写起来像普通异步函数一样自然。
下面演示一个读取本地文件的完整流程。主进程代码：
const { ipcMain } = require('electron')
const fs = require('fs/promises')
// handle注册处理器，返回值会作为Promise的resolve结果传回渲染进程
ipcMain.handle('read-file-content', async (event, filePath) => {
try {
const content = await fs.readFile(filePath, 'utf-8')
return { success: true, data: content }
} catch (err) {
return { success: false, error: err.message }
}
})preload脚本与页面调用代码：
// preload.js
const { contextBridge, ipcRenderer } = require('electron')
contextBridge.exposeInMainWorld('fileAPI', {
readContent: (filePath) => ipcRenderer.invoke('read-file-content', filePath)
})
// 页面脚本，写法与普通async函数完全一致
async function loadConfig() {
const result = await window.fileAPI.readContent('C:\\Users\\test\\config.json')
if (result.success) {
console.log('文件内容：', result.data)
} else {
console.error('读取失败：', result.error)
}
}invoke模式还有几个实用细节值得注意。第一，handle注册的处理器内部抛出的异常会被自动序列化传回渲染进程，Promise会reject，错误信息中带有Error invoking remote method的提示，方便定位问题。第二，同一个通道重复调用ipcMain.handle会直接抛错，适合在应用初始化时统一注册所有处理器。第三，IPC传输的数据默认经过结构化克隆序列化，因此不能传递函数、DOM对象或包含循环引用的对象，传大文件时应只传路径，由主进程负责实际读写，避免把几十MB的内容塞进IPC通道造成界面卡顿。
四、安全实践与常见坑位总结
通信写通了只是第一步，工程上还要守住安全底线。首先，永远不要为了图省事重新打开nodeIntegration，也不要在preload中暴露过于宽泛的接口，例如把ipcRenderer.send原样暴露等于把任意通道的调用权交给了页面，恶意脚本可以伪造任意IPC消息。正确做法是按业务封装，比如上面的openFileDialog，让页面只能触发预定义的行为。
其次，主进程处理消息时要做参数校验。渲染进程属于不可信环境，传入的filePath可能被篡改，涉及文件操作时应校验路径是否在允许的目录范围内，防止路径穿越攻击。第三，网页端加载远程内容时更要提高警惕，正式发布的应用建议开启CSP策略，并且禁用远程页面访问preload暴露的敏感API。
最后梳理几个高频问题：渲染进程回调执行多次，通常是监听器重复注册，用removeAllListeners或removeListener清理即可；invoke返回undefined，多半是handle还没注册或通道名拼写不一致；传输大Buffer失败或卡顿，应改为传文件路径；从Electron 28开始ipcRenderer模块还可以通过webFrame访问，但推荐写法仍是preload加contextBridge，这是官方长期支持的标准方案。掌握这些要点后，再看各种Electron开源项目的通信层代码，就能一眼看懂其设计意图了。
Electron主进程与渲染进程通信JavaScript桌面应用修改时间：2026-09-13 01:04:38