1.1 核心概念与设计哲学
1.1 核心概念与设计哲学
本节摘要：Electron 是一个把 Chromium 渲染引擎与 Node.js 运行时打包进同一应用壳的桌面开发框架，核心思想是"用 Web 技术写界面，用 Node 能力摸系统"。本节讲清它的三层定位（壳、双运行时、桥），以及这个设计在效率与资源代价之间做出的根本权衡，为后续架构与安全章节打地基。
从一个反直觉的事实说起
很多人第一次打开任务管理器看到 Electron 应用时会愣住：一个笔记软件，怎么后台挂着五六个进程、吃掉几百兆内存？要理解这件事，得先纠正一个常见误解——Electron 不是一个"UI 框架"。React、Vue 是框架，它们跑在浏览器里；Electron 更像一件容器：它把一个精简版 Chrome 浏览器和一整套 Node.js 运行时直接焊进你的应用安装包。用户双击图标时，操作系统启动的不是"一个程序"，而是一支小分队：管理生命周期的主进程，加上若干负责画界面的渲染进程。
这个设计哲学可以用一句话概括：**与其让 Web 应用隔着浏览器沙箱眺望系统能力，不如把浏览器本身搬进应用里，让页面直接获得长手脚的机会。**传统桌面开发里，Windows 用一套 API，macOS 用另一套，Linux 又是一套；而 Chromium 天生就是跨平台的，它在哪里渲染出来的像素都一样。Electron 赌的就是这一点：接受每个应用背上一份浏览器内核的重量，换回"一次编写、三端一致、团队零转型"。
三层结构拆开看
把 Electron 放到解剖台上，能分出三层，这个分层会贯穿整本教程：
第一层是应用壳。它负责所有"窗口之外"的事：创建和销毁窗口、注册应用菜单、接入系统托盘、管理应用生命周期。这一层跑在主进程里，用的是 Node.js 环境。
第二层是渲染层。每个窗口加载一个页面，页面跑在各自的 Chromium 渲染进程里。你熟悉的 DOM、CSS、fetch、Web Storage，全部照常工作，理论上任何现有 Web 项目都能塞进来运行。
第三层是桥。两层各干各的显然不够——界面上的按钮要触发文件读写，主进程拿到的数据要刷回界面。Electron 提供进程间通信（IPC）作为唯一的官方通道，后来又加了预加载脚本和上下文隔离作为这条通道的安全闸门。第二、四章会分别把桥的用法和锁法讲透。
用一段最小可运行的代码感受这三层。主进程入口只有几行：
// 主进程：应用的起点，拥有完整 Node.js 能力 const { app, BrowserWindow } = require('electron'); app.whenReady().then(() => { // 创建一个窗口，就是本教程主线里那个"诞生的窗口" const win = new BrowserWindow({ width: 960, height: 640, webPreferences: { contextIsolation: true, // 默认开启：页面与Node之间隔一道墙 sandbox: true // 渲染进程关进沙箱 } }); win.loadFile('index.html'); // 窗口里加载一个普通网页 });
页面这端则完全是你熟悉的 Web 写法：
<!-- 渲染进程：就是一个普通网页，只是住在应用壳里 --> <!DOCTYPE html> <html> <head><meta charset="utf-8"><title>我的第一个窗口</title></head> <body> <h1>你好，桌面世界</h1> <button id="btn">看看我住在哪</button> <script> document.getElementById('btn').addEventListener('click', () => { // 注意：这里拿不到 require、拿不到文件系统—— // 安全的 Electron 应用里，页面就是普通网页，想用系统能力必须走桥 console.log('userAgent:', navigator.userAgent); }); </script> </body> </html>
两段代码放在一处对比，能读出 Electron 最容易踩的认知坑：写惯了 Web 的人以为页面里什么都能干，写惯了 Node 的人以为主进程里也能操作 DOM——两边都错。页面干页面的，主进程干系统的，中间只有 IPC 一条路。这个约束在早期版本里并不存在（历史上页面曾能直接 require 模块），后来正是它造成了一大批安全事故，才逐步收紧成今天的默认值。这段演变在 1.2 节展开。
再用一个具体场景把三层结构的日常样貌走一遍。假设窗口里是一个笔记应用的主界面：用户点"导出 PDF"按钮，按钮的点击处理跑在渲染进程（第二层），它不能自己写磁盘，于是通过 preload 暴露的桥发出一个导出请求；请求经 IPC 到达主进程（第一层），主进程调用对话框模块让用户选保存位置，再调用外部转换工具生成文件，最后把结果经 IPC 送回页面，界面弹出"导出成功"。整个往返里，页面自始至终没有接触过文件系统的一个字节——但用户得到了一个躺在磁盘上的 PDF。这个分工在后面的章节里会反复出现，直到你闭上眼睛也能画出这条请求的往返路径。
代价要说在前面
设计哲学的另一面是账单。每个 Electron 应用自带一份 Chromium，意味着安装包普遍上百兆、空窗口内存占用远超原生应用、多窗口场景下资源线性增长。社区对此的嘲讽流传很广——"每个窗口都是一个独立的 Chrome"。辩护与反驳都有道理，但工程决策不能靠段子，要看场景：对编辑器、聊天工具这类界面复杂、迭代频繁的应用，人时成本远高于内存成本；对常驻后台的轻量工具，这份账单就重得离谱。1.4 节的横向对比会给出一套可操作的判断标准。
本节要点回顾
- 定位：Electron 是应用壳而非 UI 框架，等于"Chromium 渲染 + Node.js 能力 + IPC 桥"三件套；
- 核心赌注：用每个应用自带浏览器内核的重量，换跨平台一致性与前端团队零转型；
- 三分法：主进程管窗口与生命周期，渲染进程画界面，IPC 是两者唯一官方通道；
- 认知坑：页面里没有 Node，主进程里没有 DOM，跨界必须过桥；
- 代价前置：包体积与内存是结构性成本，选型时必须摆上桌面评估。
下一节把时间轴拉直：这套设计是怎么一步步变成今天这副样子的，尤其是那几次"破坏性"的安全转向。