在 Electron 应用的整个生命周期中，稳定性是最容易被忽视却又最致命的一环。无论界面设计得多精美、功能多强大，一旦应用毫无征兆地闪退或白屏，用户信任就会瞬间崩塌。理解崩溃的根源并对其进行分类，是搭建防御体系的第一步。
Electron 的崩溃按照发生位置可分为两大类：主进程崩溃和渲染进程崩溃。两者的成因、表现和应对策略截然不同。
21.1.1 主进程崩溃
主进程是整个应用的大脑，管理着窗口创建、系统交互、应用生命周期等核心功能。一旦主进程崩溃，所有窗口会立即消失，系统托盘图标也会随之移除，用户看到的就是一次完整的“闪退”。
常见原因
- 未捕获的异常：主进程中任何一个同步抛出的异常如果没被
try/catch包裹，都会导致进程退出。例如JSON.parse解析非法数据、访问undefined的属性、第三方库内部抛出错误等。 - 未处理的 Promise 拒绝：从 Node.js 15 开始，未捕获的 Promise rejection 默认会导致进程退出（
unhandledRejection模式）。如果你的async函数或 Promise 链中抛错而没有.catch，主进程将直接终止。 - 原生模块崩溃：如果你在主进程中调用了 C++ 原生模块（如
better-sqlite3、自定义 node-addon），模块内部的空指针解引用、内存越界等错误会触发段错误（SIGSEGV），表现为整个进程瞬间消失，且 JavaScript 层面根本无法捕获。 - 内存泄漏与 OOM：主进程长时间运行可能导致内存持续增长。如果泄漏达到系统极限，操作系统会直接杀掉进程。这在需要维护大量全局状态或定时器的应用中尤为常见。
- 阻塞操作导致无响应：主进程长时间执行同步阻塞任务（如大文件读写、密集计算）会冻结事件循环，虽然进程未死但已失去响应。如果此时触发了系统看门狗或用户强制结束，效果等同于崩溃。
表现特征
主进程崩溃是“全或无”的：不仅仅是当前窗口消失，而是整个应用退出。在 macOS 上你会看到应用图标从 Dock 中移除，在 Windows 上任务管理器里进程消失。崩溃后通常不会自动重启，除非你实现了专门的守护机制。
21.1.2 渲染进程崩溃
渲染进程负责展示界面并处理用户交互。每个 BrowserWindow 或 BrowserView 都是一个独立的渲染进程。因为每个窗口进程相互隔离，单个渲染进程的崩溃通常只会让那个窗口变成白屏或显示“页面崩溃”提示，而不会波及主进程和其他窗口。
常见原因
- JavaScript 运行时错误与死循环：前端代码中无限循环、递归过深导致栈溢出、加载不存在的模块等，都会使渲染进程卡死或崩溃。Chromium 引擎最终会检测到页面无响应并终止该进程。
- 内存消耗超标：渲染进程中如果渲染了巨量 DOM 节点、持有超大 Canvas 或 WebGL 资源、或在循环中持续分配对象而不释放，会导致该进程的内存使用量迅速膨胀。Chromium 有 OOM 监控机制，会主动杀死消耗过多的渲染进程。
- GPU 进程关联故障：Electron 使用 GPU 加速渲染。如果渲染进程触发了显卡驱动 bug 或使用不支持的 WebGL 特性，可能导致 GPU 进程崩溃，进而拖垮与之关联的一个或多个渲染进程。
- 扩展与第三方内容：在渲染进程中加载不受信任的外部内容（如用户自定义插件、广告、第三方 iframe）时，这些内容可能会执行恶意或低质量代码导致页面崩溃。
- IPC 消息处理异常：如果渲染进程通过 IPC 接收到格式错误的数据，并试图执行危险操作（如使用
eval解析或直接写入 DOM），引发的错误同样会造成进程崩溃。
表现特征
Electron 默认会在渲染进程崩溃时显示一个“页面崩溃”的静态错误页面。如果你自定义了崩溃行为（例如通过 win.webContents.on('crashed') 事件），可以实现自动重载当前页面。渲染进程崩溃的典型现象是：某个窗口突然变白或显示错误提示，而其他窗口正常，系统托盘、全局快捷键等功能依然可用。
关键区分
在实际排查时，快速判断是主进程还是渲染进程崩溃的方法是：崩溃后如果系统托盘图标还在（且可交互），窗口标题栏虽然变白但窗口框架还在，那么极可能是渲染进程挂掉了；如果整个应用连同托盘一起从任务管理器中消失，没有任何响应，那么几乎可以断定是主进程崩溃。
搞清楚这两类崩溃的成因后，下一节我们将介绍如何在代码层面对它们进行监控和捕获，让应用在灾难面前表现得更加可靠。