从外部看，Electron 是一个能让你用 JavaScript 写桌面应用的框架；从内部看，它是一个由三层技术栈精密咬合而成的运行时。理解这三层分别做什么、它们之间如何协作，是掌握 Electron 开发的关键。
1.4.1 第一层：Chromium 内核 —— 界面渲染引擎
Electron 应用的所有可视化内容都由 Chromium 负责绘制。Chromium 是 Google Chrome 浏览器背后的开源项目，它提供了：
- 完整的 HTML5、CSS3、JavaScript（V8 引擎）支持。
- 硬件加速的 2D/3D 图形渲染（Canvas、WebGL）。
- 媒体播放、WebRTC、Service Worker 等现代浏览器特性。
- 开发者工具（DevTools），让你可以像调试网页一样调试桌面界面。
在 Electron 中，每个应用窗口都对应一个独立的 Chromium 渲染进程。这意味着你的窗口之间天然享有沙箱隔离 —— 一个页面崩溃不会拖垮整个应用。同时，渲染进程中的代码默认运行在 Web 环境中，你可以毫无障碍地使用任何前端框架和 npm 包。
实际开发中你需要注意的：
- Chromium 的版本决定了你能使用哪些最新的 Web 特性。你可以通过
process.versions.chrome查看当前 Electron 内置的 Chromium 版本。 - 渲染进程的性能优化与普通 Web 页面类似：避免频繁的重排重绘，合理使用虚拟滚动，及时回收内存。
- 如果你使用了
<webview>或BrowserView，它们会创建额外的 Chromium 渲染进程，注意管理进程数量和内存消耗。
1.4.2 第二层：Node.js 运行时 —— 后端能力层
光有浏览器的渲染能力，你只能做一个漂亮的网页，无法触达操作系统。Node.js 的嵌入弥补了这一缺失，它赋予了 Electron 完整的后端开发能力：
- 文件系统：
fs模块让你能直接读写用户硬盘上的文件，不需要经过浏览器的文件选择器。 - 网络：
http、net、dgram等模块允许你创建本地服务器、TCP/UDP 客户端，甚至实现自定义协议。 - 系统操作：
child_process可以执行系统命令，os可以获取 CPU、内存、网络接口信息。 - C++ 扩展：你可以编写 Node.js 原生插件（
.node文件），直接调用操作系统底层 API 或用 C++ 做高性能计算。
在 Electron 应用中，Node.js 环境主要运行在主进程和预加载脚本中。出于安全考虑，现代 Electron 默认禁用了渲染进程中的 Node.js 集成（contextIsolation: true），但通过预加载脚本的 contextBridge，你可以安全地将部分 Node.js 能力暴露给界面使用。
实际开发中你需要注意的：
- Node.js 的版本（
process.versions.node）决定了你能否使用最新的 ES 特性或 Node API。 - 原生模块（如
sqlite3、node-canvas）需要针对 Electron 的 Node.js 版本重新编译。通常使用electron-rebuild工具自动完成。 - 不要在主进程中执行大量同步或高 CPU 占用操作，这会阻塞整个应用的事件循环，导致窗口无响应。建议将耗时任务放到子进程或 Worker 线程中。
1.4.3 第三层：Native API 抽象层 —— 系统桥接层
如果只有 Chromium 和 Node.js，你仍然无法创建一个真正的桌面应用 —— 没有窗口、没有菜单、没有托盘图标，也无法响应系统的深色模式切换。这中间缺失的一环，就是 Electron 自己实现的那层 C++ 代码，它充当了 JavaScript 与操作系统原生 API 之间的翻译官。
这层可以称为系统桥接层，它负责：
- 窗口管理：创建原生窗口、控制标题栏、边框、大小、位置、透明度、置顶等。这些最终调用的是 Windows 的 HWND、macOS 的 NSWindow、Linux 的 X11/Wayland 接口。
- 系统菜单：在 macOS 上创建全局菜单栏，在 Windows/Linux 上创建窗口内嵌菜单，支持快捷键绑定和角色（role）定义。
- 系统对话框：
dialog.showOpenDialog()、dialog.showSaveDialog()等 API 会弹出原生的文件选择、消息确认、错误弹窗，体验与系统完全一致。 - 设备能力：系统托盘（Tray）、全局快捷键（globalShortcut）、系统通知（Notification）、自动更新（autoUpdater）、剪贴板（clipboard）、电源状态（powerMonitor）等。
- 平台适配：
process.platform的值判断、app.getPath()返回符合各平台惯例的目录（如 AppData、Application Support）、窗口的vibrancy（毛玻璃）效果在 macOS 上生效而在 Windows 上被忽略。
这层代码是用 C++ 或 Objective-C++ 编写的，以 Node.js 原生模块（.node）的形式加载到主进程中。对 JavaScript 开发者来说，你不需要直接跟 C++ 打交道，只需调用 Electron 的 JavaScript API，背后的桥接层会自动处理平台差异。
实际开发中你需要注意的：
- 某些平台独有的功能（如 macOS 的 Touch Bar、Windows 的任务栏缩略图按钮）需要通过条件判断来调用，避免在其他系统上报错。
- 桥接层的 API 通常只能在主进程中调用，如果你需要在渲染进程中使用，必须通过 IPC 间接调用。
- 当 Electron 的 API 无法满足需求时，你可以自己编写原生模块（使用
N-API或node-addon-api）来扩展系统能力，但要注意编译和分发的复杂性。
1.4.4 三层的协同工作方式
这三层并非孤立存在，而是紧密交织在一起。下面用一个典型场景 —— 用户在界面上点击“保存文件”，触发本地保存流程 —— 来展示它们是如何协作的：
- 渲染进程（Chromium 层）
用户点击用 HTML <button> 和 CSS 样式制作的“保存”按钮，触发 JavaScript 事件处理函数。渲染进程无法直接访问文件系统，因此它通过预加载脚本暴露的 window.api.saveFile() 方法，使用 ipcRenderer.invoke 发送一个 IPC 消息给主进程。
- 主进程（Node.js 层）
主进程中的 ipcMain.handle 接收到消息。它先调用 Native API 抽象层 提供的 dialog.showSaveDialog()，弹出一个原生的系统保存对话框，让用户选择保存路径。这个对话框在 Windows 上用的是 Windows 原生控件，在 macOS 上是 Cocoa 面板。
- 主进程（Node.js 层）
用户选好路径后，showSaveDialog 返回文件路径。主进程使用 Node.js 的 fs.writeFile() 将数据写入该路径。写入完成后，主进程通过 IPC 将结果（成功或失败）返回给渲染进程。
- 渲染进程（Chromium 层）
渲染进程收到主进程的响应，更新界面，比如显示“保存成功”的提示消息。
整个过程中，Chromium 只管展示和交互，Node.js 处理文件写入，Native API 抽象层提供了系统原生对话框。每一层各司其职，通过 IPC 串成完整的功能链。
理解这三层架构，你就能明白 Electron 的“超能力”从何而来，也能在遇到问题时快速定位：界面问题查 Chromium，文件或网络问题查 Node.js 模块，窗口行为或系统级功能找 Electron 的 Native API。这种清晰的分层不仅降低了学习曲线，也让应用的调试和维护变得更有条理。