在构建 Electron 应用时，你是否应该把所有逻辑塞进一个进程，还是严格遵循主进程与渲染进程分离的架构？这个问题的答案直接决定了你的应用在稳定性、安全性和可维护性上的表现。本节将从实际工程角度讨论两种选择的利弊，帮助你理解为什么 Electron 的多进程模型不是一个可选的插件，而是框架的核心设计基石。
3.1.1 什么是“单进程”与“多进程”
在 Electron 的语境中，单进程通常不是指只有一个操作系统进程，而是指你绕过主进程、将所有系统调用和业务逻辑都放在渲染进程中执行。比如在渲染进程里直接引入 fs 模块读写文件，甚至直接创建 BrowserWindow。
多进程则严格遵循 Electron 官方的推荐架构：
- 主进程 负责应用生命周期、窗口管理、系统 API 调用和后台任务。
- 每个窗口 对应一个独立的渲染进程，只做界面渲染和交互，任何需要系统权限的操作都通过 IPC 请求主进程代为执行。
3.1.2 为什么会有单进程的冲动
很多新手（甚至一些追求效率的老手）会觉得多进程架构“麻烦”：只是读写个本地文件，为什么要来回发送消息？直接 require('fs') 不是更简单吗？这种想法在快速原型阶段尤其常见，它确实能省去一些 IPC 样板代码。但在这份“便利”背后隐藏着几个严重的代价。
3.1.3 多进程架构的真实价值
1. 稳定性：一个页面崩溃，应用不挂
Chromium 的渲染进程是运行在沙箱中的，每个窗口独立。如果你的渲染进程由于内存泄漏、死循环或未捕获的异常崩溃了，Electron 会通知主进程这个窗口挂掉，主进程只需要销毁该窗口并给用户一个友好的提示，应用的其他部分仍然正常运行。
如果你把核心业务逻辑放在渲染进程，那一次 JavaScript 错误可能直接导致整个窗口消失。更糟的是，如果你把只有一份的“数据管理服务”也放在了渲染进程，窗口崩溃时还没来得及保存的数据可能就永远丢失了。将关键任务交给主进程（它不会因为渲染崩溃而受影响），是保障数据完整性和应用可用性的重要手段。
2. 安全性：最小权限原则
默认情况下（contextIsolation: true 和 nodeIntegration: false），渲染进程无权使用 Node.js 或 Electron 的原生模块。它就像普通的网页，只能操作 DOM 和有限的 Web API。这极大地限制了 XSS 攻击的危害 —— 即使攻击者在你的界面里注入了恶意脚本，他也无法访问本地文件系统或执行系统命令。
相反，如果你在渲染进程中打开了 nodeIntegration，任何一个第三方广告脚本、用户可编辑的富文本内容中的恶意代码，都可能读写用户的敏感文件。将系统能力的调用收拢到主进程，并通过 contextBridge 暴露经过严格校验的接口，是现代 Electron 应用的基本安全准则。
3. 资源隔离与性能优化
浏览器本身有成熟的内存管理策略：当某个标签页占用过多资源时，系统可以回收它的渲染进程。Electron 继承了这一优势。你可以为主进程预留相对固定的资源，而各个渲染进程则按需分配和释放。只要通过 IPC 进行异步通信，主进程即使正在处理大文件读写，也不会阻塞界面渲染和动画。
另外，如果你的应用需要长时间执行 CPU 密集型任务（如 AI 推理、视频编码），放在渲染进程很容易导致界面卡死；放在主进程同样会阻塞所有窗口的事件循环。多进程模型自然延伸出第三种选择：创建独立的 utility 进程或工作线程，这正是 Electron 多进程架构的扩展能力。
3.1.4 单进程模式的真正用武之地
强调多进程的优势并不意味着单进程毫无价值。在一些特定的工具类场景中，你可以利用 BrowserWindow 的 webPreferences 配置将一个窗口的渲染进程作为“特权进程”，直接调用 Node.js，而其他窗口保持沙箱。比如一个数据管理工具，GUI 部分用沙箱渲染进程，后台数据库操作窗口则可以开启 nodeIntegration 并使用 remote 模块（虽已弃用但仍有类似方案）。这种方式在受信任的小范围内，可以显著降低通信的复杂度。
还有一种情况：当你在开发一个 单一窗口、无任何网络内容加载的离线工具 时，且用户环境完全可信，直接开启 nodeIntegration 并关闭沙箱确实能大幅缩短开发时间。许多个人项目或内部脚本的 GUI 包装就是这样实现的。关键在于 有意识的取舍，而不是无知的默认行为。
3.1.5 实用的选择指南
从真实项目的经验来看，以下几点可以帮助你做出决定：
- 如果你的应用有多个窗口或未来可能扩展，从一开始就采用严格的多进程架构会省去大量重构的痛苦。
- 如果你需要在界面中使用第三方远程内容（广告、用户生成的 HTML、第三方登录页面等），必须关闭渲染进程的 Node.js 权限，否则安全漏洞只是时间问题。
- 如果你追求长期维护性和团队协作，多进程架构的职责分离会让代码组织更清晰：主进程代码处理“系统的事”，渲染进程代码处理“界面的事”，互不侵犯。
- 如果只是一个单窗口、完全离线的个人小工具，可以考虑简化 IPC 流程，但仍建议保留
contextIsolation并仅通过预加载脚本暴露最低限度的 Node.js 功能，因为这个安全习惯养成后对以后的任何项目都有益无害。
3.1.6 总结
Electron 的多进程架构本质上是一种 “用短期的编码复杂度换取长期的安全和稳定” 的设计。它强制你将系统能力封装在主进程中，通过可控的通道暴露给界面，从而在崩溃隔离、攻击面控制和资源管理上得到保护。这个设计取舍在大型工具如 VS Code、Slack、Figma 中经历了严峻的验证，值得你在动手写第一行生产代码前认真掌握。当你熟悉这套模式后，会发现所谓的“样板代码”其实是一种值得的保险，它为你的应用提供了操作系统级别的韧性。