Electron 的多进程模型是它区别于传统桌面框架的一个核心特征，也是开发者从单页面 Web 应用转入桌面开发时最容易忽视的“双刃剑”。理解这个模型带来的实际收益和隐性成本，能帮助你在设计应用架构时做出更务实的取舍。
3.4.1 稳定性提升：崩溃隔离带来的韧性
Electron 的进程架构直接继承了 Chromium 的多进程设计。默认情况下，主进程只有一个，而每个 BrowserWindow 都运行在一个独立的渲染进程中，此外还有 GPU 进程、网络服务进程等底层辅助进程。这种隔离最直观的好处是：一个窗口的崩溃不会拖垮整个应用。
假设你在一个 Electron 应用中同时打开了三个窗口：编辑器、预览窗和插件设置面板。如果用户加载了一个包含内存泄漏的第三方插件，导致设置面板的渲染进程耗尽内存而崩溃，用户只会看到那个窗口消失或显示错误页面。主进程及其余两个窗口依然完好，可以继续保存数据或弹出提示。这在长时间运行的生产力工具中至关重要——用户不会因为一个意外而丢失所有工作状态，恢复成本远低于整个应用闪退。
这种稳定性还体现在功能解耦上。你可以把高风险的逻辑（例如解析用户上传的不安全文件、执行第三方脚本）放到一个独立的渲染进程甚至子进程中，就算出了事，也不会污染主进程的关键状态。这种防御性编程在原生开发中往往需要手动建立沙箱，而 Electron 直接把它变成了架构的默认行为。
3.4.2 通信开销：IPC 是有成本的
进程隔离的好处伴随着一个不可回避的代价：任何跨进程的交互都必须经过 IPC（Inter-Process Communication，进程间通信）。Electron 的 IPC 底层基于 Chromium 的 Mojo 通道，虽然经过了大量优化，但仍不可避免地引入序列化、反序列化以及上下文切换的成本。
在简单场景下，这种开销几乎可以忽略——比如用户点击“打开文件”按钮，渲染进程发送一个 IPC 请求，主进程弹出原生对话框并返回路径，整个过程耗时通常在微秒到毫秒级，用户完全无感。但当通信频率或数据量上升时，瓶颈就会显现。
常见的问题场景包括：
- 高频事件：例如在绘图应用中实时同步鼠标坐标给主进程做全局坐标计算，如果每帧（16ms）都 IPC 一次，性能会迅速恶化。
- 大数据传输：例如通过 IPC 传递一个几百 MB 的文件 Buffer，需要将整个数据复制到共享内存再传送，不仅慢，还可能阻塞其他 IPC 调用。
- 链式调用：渲染进程 A 需要主进程 → 主进程再请求渲染进程 B 的数据，这样的往返延迟在交互密集时会有可感知的停顿。
实际的性能测试中，小负载的 ipcRenderer.invoke 往返延迟通常在 0.1–0.5ms 量级（取决于硬件），但如果携带大对象，序列化成本会线性增长。这就是为什么一旦你需要做高频率的数据同步（比如主进程监控文件夹变化，实时将文件列表传给 UI），必须警惕 IPC 不要变成通道上的“堵车”。
3.4.3 内存占用：每个渲染进程都不是免费的
Chromium 的每个渲染进程都是一个完整的浏览器环境，包含自己的 JavaScript 引擎、DOM 树、事件循环和 GPU 纹理缓存。这意味着每多打开一个 BrowserWindow，你的应用就会新增一笔不小的内存账单。根据窗口内容的复杂度，单一渲染进程的内存占用通常在 50MB 到 200MB 之间，加载了大型前端框架或图片/视频的页面很轻易就超过 300MB。
这带来的现实问题是：如果你不加节制地创建新窗口，应用的内存总占用会迅速膨胀。一个拥有四个窗口的轻量工具应用，启动后可能已经占用了 500MB 以上的内存，而在用户眼中它可能只是“一个简单的笔记软件”。与传统原生应用（如记事本）对比，这种资源消耗的感知落差往往会引发用户抱怨。
不过，这种代价也不是完全无法优化。社区和官方都提供了一些策略来平衡稳定性与内存消耗：
- 共享渲染进程：通过
webPreferences.affinity或sandbox配置，可以让多个BrowserWindow或BrowserView共享同一个渲染进程。这种做法牺牲了进程隔离的崩溃保护，但能大幅减少内存占用，适合那些内容互信且不需要极高稳定性的场景（如设置页、关于窗）。 - 使用
BrowserView替代独立窗口：BrowserView是在现有窗口内嵌入额外的网页视图，它仍然可以独立加载内容，但通常比完整的BrowserWindow开销更小，并且界面更紧凑。 - 延迟加载与回收：不在应用启动时一次性创建所有窗口，而是按需打开，并在窗口关闭时确保销毁
BrowserWindow对象、移除事件监听，避免内存泄漏。 - WebContents 的复用：如果只是切换显示内容，可以复用同一个窗口的
webContents.loadURL，而不是每次都打开新窗口。
3.4.4 工程上的权衡：没有银弹
多进程模型带来的这些优势和代价，最终会落到一个具体的工程决策上：你的应用究竟需要几个窗口？怎么划分进程职责？
一个典型的反面例子是：一个聊天应用为每一个聊天会话创建一个独立的窗口，每个窗口里跑着完整的 React 应用。结果是内存爆炸、窗口管理混乱、通知同步复杂。更务实的设计是单窗口多标签，标签切换复用同一个渲染进程，或者最多为特殊功能（如视频通话）开一个独立窗口。
在架构设计时，可以从“崩溃影响面”和“通信频率”两个维度去衡量。如果一个模块的崩溃会导致数据丢失，那它应该放在健壮性最强的主进程中，或者通过合理的自动重启机制保护。如果两个界面组件之间需要微秒级的数据同步（如实时波形图），把它们放在同一个渲染进程内比跨进程 IPC 要高效得多。
总结这一节的要点：Electron 的多进程模型给了你“稳定性”这张安全网，让你的应用能承受局部故障而不整体坍塌；但它同时也在“性能”和“资源”上征收了一笔税款。成熟的 Electron 开发者会清醒地认识到这笔账，在设计窗口结构和数据流时，既不滥用进程隔离，也不过度追求内存节省而牺牲稳定性。这种平衡感，正是驾驭 Electron 框架的关键能力之一。