Electron 应用在运行时，并不是一个单一的程序在孤军奋战，而是由几个职责分明的进程协同工作。理解这些进程各自的定位和边界，是写出稳定、安全、可维护的 Electron 应用的基础。官方明确划分了三类核心角色：主进程、渲染进程和预加载脚本。本节会逐一说明它们分别做什么、不能做什么，以及在实际开发中如何正确地让它们配合。
3.2.1 主进程 —— 应用的大脑
主进程是 Electron 应用的“指挥中心”。每个应用有且只有一个主进程，它在 app 模块的 ready 事件触发后开始运行，负责管理整个应用的生命周期：创建窗口、注册系统事件、调用操作系统底层 API，以及在应用退出时执行清理工作。
主进程的核心职责包括：
- 窗口管理：通过
BrowserWindow创建和控制应用里的每一个窗口，设置窗口大小、位置、标题、背景色、是否可缩放等属性。 - 系统集成：创建原生菜单（
Menu）、系统托盘（Tray）、全局快捷键（globalShortcut），发送系统通知（Notification），以及监听电源状态、网络状态等系统级事件。 - 文件与数据访问：由于主进程拥有完整的 Node.js 环境，它可以自由使用
fs读写文件、执行child_process调用外部程序，甚至运行一个本地 HTTP 服务。 - 处理 IPC 请求：主进程是渲染进程与系统能力之间的“代理”。渲染进程想要打开一个文件选择对话框，必须通过 IPC 向主进程发送请求，由主进程调用
dialog.showOpenDialog后把结果传回去。
从代码的组织形式看，主进程通常就是一个 Node.js 脚本（如 main.js），运行在服务端环境中。它不能直接操作 DOM，也没有 window 对象，但它拥有所有 Node.js 的模块和 Electron 原生模块。这种“只负责后端逻辑”的设计，天然地促使开发者遵循关注点分离的原则。
实际开发中需要注意的几点：
- 主进程的阻塞会直接影响整个应用的响应。如果在主进程中执行耗时的同步操作（如大文件的同步读取），所有窗口都会卡死。正确做法是使用异步 API 或将繁重任务交给子进程或 Worker 线程。
- 主进程的崩溃意味着整个应用退出。因此，对于关键路径的代码要做好异常处理，避免一个未捕获的错误直接杀死主进程。
- 窗口对象的生命周期需要细心管理：窗口关闭时最好显式地将引用置为
null，防止内存泄漏；多窗口应用还要注意，当所有窗口都关闭后，app的window-all-closed事件是否会导致应用退出（macOS 上通常不需要退出，其余平台默认退出）。
3.2.2 渲染进程 —— 用户所见的一切
每一个 BrowserWindow 实例都会启动一个独立的渲染进程。渲染进程实际上就是一个 Chromium 标签页，它加载一个 HTML 文件，并运行其中的 JavaScript、CSS，最终将界面呈现给用户。对于前端开发者来说，这就是他们最熟悉的“战场”：DOM 操作、事件监听、React/Vue 组件树、Canvas 动画或者 WebGL 渲染，都可以在这里完成。
渲染进程的主要特征：
- 独立的沙箱环境：每个窗口有自己的渲染进程，一个窗口崩溃只影响该窗口本身，不会拖垮主进程或其他窗口。这种“多进程架构”借鉴了 Chrome 的稳定性设计。
- Web 生态的全部能力：可以直接使用浏览器提供的所有 API ——
fetch、localStorage、WebSocket、requestAnimationFrame、IndexedDB等等。 - 受限的 Node.js/Electron 访问：出于安全原因，现代 Electron 应用（
contextIsolation: true，从 Electron 12 开始是默认值）在渲染进程中不再能直接访问 Node.js 的require和 Electron 原生的ipcRenderer等模块。取而代之的是通过预加载脚本暴露有限、安全的方法。
渲染进程的职责可以总结为：只管用户界面和交互。它接收用户输入，展示数据，发送请求给主进程处理底层操作，并根据主进程返回的结果更新界面。这种单向依赖让渲染进程变得轻量且易于调试 —— 你可以像调试普通网页一样打开 Chrome DevTools，检查元素、打断点、看网络请求。
实际开发中需要注意的几点：
- 渲染进程的性能直接决定了用户感知的流畅度。长时间运行的同步脚本或过于频繁的重绘可能导致窗口响应迟钝。善用 Web Worker 或
requestIdleCallback来分摊计算任务。 - 不要尝试在渲染进程中做系统级操作。即便某些配置允许你这样做（比如设置
nodeIntegration: true），也应该视为反模式。它不仅带来巨大的安全风险，还会让应用失去进程隔离带来的稳定性优势。 - 多个渲染进程之间的通信不能直接通过全局变量或事件总线实现（它们运行在不同的进程中），必须通过主进程作为中介进行转发。
3.2.3 预加载脚本 —— 安全的桥梁
预加载脚本是附着在渲染进程上的一个特殊脚本，在网页内容开始加载之前运行。它是主进程能力和渲染进程界面之间的唯一合法通道。正是因为它的存在，我们才能实现“渲染进程安全地调用系统能力”这一目标。
工作原理：
- 预加载脚本运行在一个混合环境里：它有权使用 Node.js 的
require和 Electron 的contextBridge、ipcRenderer等模块，但它不能直接访问 DOM（document对象不可用），也无法操作页面内容。 - 开发者通过
contextBridge.exposeInMainWorld方法，将经过严格筛选的 API 挂载到渲染进程的window对象上。这样，渲染进程的网页脚本就可以通过window.electronAPI.openFile()这样的方式，间接调用预加载脚本暴露的方法，而这些方法内部则通过ipcRenderer与主进程通信。
一个典型的预加载脚本可能长这样：
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('electronAPI', {
openFile: () => ipcRenderer.invoke('dialog:openFile'),
saveFile: (content) => ipcRenderer.invoke('dialog:saveFile', content),
onMenuAction: (callback) => ipcRenderer.on('menu-action', callback),
});渲染进程中则直接使用：
const filePath = await window.electronAPI.openFile();为什么说它是“安全桥梁”？
在旧版本的 Electron 中，常见的做法是直接开启 nodeIntegration: true，让渲染进程能够自由使用 require。这意味着网页脚本可以轻松读取用户磁盘上的任意文件或执行系统命令，一旦应用加载了恶意的远程内容（或者存在 XSS 漏洞），后果不堪设想。预加载脚本和 contextIsolation 的出现，将渲染进程彻底隔离在一个纯净的浏览器沙箱里，只通过预定义的一组 API 与主进程交互。攻击者即使控制了渲染进程，也无法直接访问 Node.js 或 Electron 的原生模块。
实际开发中需要注意的几点：
- 只暴露必要的方法，避免把整个
ipcRenderer对象原封不动地传给渲染进程。最小权限原则是安全的核心。 - 尽量使用
ipcRenderer.invoke和ipcMain.handle这对异步、Promise 化的 IPC 通信方式，避免使用基于事件的send/on（除非确实需要主进程主动推送消息给渲染进程）。 - 预加载脚本在
BrowserWindow的webPreferences.preload选项中指定，路径需要根据构建环境正确配置（通常使用绝对路径）。
3.2.4 三大角色协作实例
用一个最常见的场景来串联三个角色：用户在界面上点击“导出数据”按钮，应用将一段 JSON 文本保存到用户选择的位置。
- 渲染进程：按钮绑定点击事件，调用
window.electronAPI.exportData(jsonString)。 - 预加载脚本：
exportData方法内部执行ipcRenderer.invoke('export-data', jsonString)，将数据发送给主进程。 - 主进程：通过
ipcMain.handle('export-data', async (event, jsonString) => { ... })接收请求。它调用dialog.showSaveDialog弹出系统原生保存对话框，获取用户选择的路径后，用fs.writeFile写入数据，最后返回成功状态。 - 预加载脚本 将主进程返回的结果通过 Promise 传递回渲染进程。
- 渲染进程 根据结果显示提示消息，全部操作完成。
整个流程中，界面逻辑只感知到一次异步函数调用，根本没有机会接触文件系统或系统对话框的底层细节。三个角色各司其职，确保了代码的可测试性、安全性和清晰的结构。
可以说，理解了这三个核心进程的角色和协作方式，你就已经掌握了 Electron 应用架构的精髓。之后再深入具体的 API 或者优化策略时，都会自然地放在这个三角框架中去思考，也就能避免很多典型的错误用法。