人人都会AI编程

22.1 安装包体积构成分析

更新时间：2026-07-11

Electron 应用最常被讨论的一个点，就是它的安装包体积。随便打包一个空项目，出来的安装包就要 100 MB 起步，这让习惯了原生应用几十兆甚至几兆体积的开发者感到错愕。但体积大并不是因为“框架写得臃肿”，而是因为它实实在在地打包了整个浏览器内核和 Node.js 运行时。这一节我们拆开来看，一个典型的 Electron 安装包到底由哪些部分组成，每一部分占多少空间，以及在实际项目中你可以对哪些地方“动刀”。

22.1.1 安装包内部的四个主要部分

当你用 electron-builder 或 electron-forge 打完包之后，把安装包解压（或直接查看未压缩的应用目录），会看到类似下面的结构（以 macOS 的 .app 包和 Windows 的 resources 目录为例）：

macOS 示例：

YourApp.app/
└── Contents/
    ├── MacOS/               # Electron 主进程可执行文件
    │   └── YourApp          # 实际就是 Electron 的可执行文件，通常 50–80 MB
    ├── Resources/
    │   ├── app.asar         # 你的应用代码（打包为 asar 格式）
    │   ├── electron.icns    # 图标
    │   └── ...              # 其他资源（locales 等）
    └── Frameworks/
        ├── Electron Framework.framework/  # Chromium 内核文件（> 150 MB）
        └── ...              # 辅助库

Windows 示例：

YourApp/
├── YourApp.exe              # Electron 主程序（通常几十 MB）
├── resources/
│   ├── app.asar             # 你的业务代码
│   └── ...                  # 其他资源
├── locales/                 # 多语言包（可选）
├── swiftshader/             # 软件渲染库（用于无 GPU 环境）
└── *.dll                    # Chromium 与 Node.js 运行依赖的动态库

可见，安装包的体积主要由四个部分构成：

  1. Chromium 运行时（最大头）

包括渲染引擎、V8 JavaScript 引擎、Blink 排版引擎、网络栈、图形栈、音视频解码器、字体渲染模块等。这部分就是整个浏览器的“内核”，在 macOS 上通常是 Electron Framework.framework，在 Windows/Linux 上是大量的 DLL 或 SO 库文件。
典型体积：未压缩状态下，Chromium 本身约占 120–180 MB，经过安装包压缩后通常在 60–90 MB（视平台和 Electron 版本而定）。

  1. Node.js 运行时

Electron 内嵌了完整的 Node.js 环境，包含 V8 引擎（与 Chromium 共享，但会额外增加 Node.js 特有的底层模块）、libuv 事件循环、crypto、fs 等原生模块的二进制文件。这一部分相对紧凑。
典型体积：额外增加约 10–20 MB。

  1. Electron 框架层

Electron 自身的 C++ 代码，负责连接 Chromium 和 Node.js，提供所有原生 API（窗口、菜单、系统托盘、通知、IPC 等）。这些代码量不大，基本已经合并到主可执行文件中。
典型体积：约 2–5 MB。

  1. 你的应用代码与资源

包括 app.asar 打包的全部业务代码、前端静态资源（HTML/CSS/JS/图片/字体）、npm 依赖（打包进去的部分）、以及你自己添加的其他二进制库或数据文件。
典型体积：最简单的空项目可能在几百 KB 到几 MB，但一个真实项目（比如 VS Code、Slack）可能会追加数十 MB 甚至更多。

把以上四部分加起来，一个什么都不写的 Electron 空壳应用，在 macOS 上解压后的占用大约在 170–200 MB，打包成 .dmg 后通常显示为 80–110 MB（因为安装包有压缩）。Windows 上类似，.exe 安装包通常在 80–100 MB 区间。这还只是“工厂配置”，没有加你自己的大型资源。

22.1.2 为什么体积无法大幅缩减

有些开发者会问：“不是可以选择只打包需要的 Chromium 特性吗？” 答案是：Electron 的 Chromium 是经过裁剪的，但可裁剪的空间有限。

  • Chromium 是一个整体：渲染 HTML、执行 JavaScript、绘制 Canvas、播放视频这些前端核心能力，相互间高度耦合。你不可能只用“渲染文本”而不加载排版引擎和图形栈。
  • 系统调用依赖：比如文件选择对话框需要调用系统 API，但 Electron 并没有为每个平台重写一个轻量的文件对话框，而是桥接了 Chromium 的 UI 框架层，这就意味着必须带上相关的底层 UI 组件代码。
  • Node.js 的全量打包：虽然你实际可能只用到 fs、path、child_process 这几个模块，但 Node.js 的标准库是作为一个整体编译的，无法在运行时按需裁剪。官方虽然提供了 node-slim 之类的一些方案，但在 Electron 生态中没有得到官方支持，且容易引发兼容性问题。

因此，任何 Electron 应用的起步体积都是 100 MB 级别的，这一点无法回避。在商业化场景中，你需要做的是让用户理解“它之所以大，是因为它内置了一个完整的沙箱浏览器”，就像移动端的 WebView 应用虽然没有 Runtime，但实际也依赖系统自带的 WebView（体积算在了系统头上）。在桌面端，这个 Runtime 代价就需要由应用自己承担。

22.1.3 真实项目中你可以优化的空间

虽然“底座”省不了，但你确实可以让最终安装包变得更精简。下表列出了一些常见的优化手段和效果：

| 优化方法 | 预估节省空间 | 操作难度 | 备注 |
|---------|------------|--------|------|
| 剔除未使用的语言包（只保留 English 或你需要的 locales） | 5–15 MB | 极低，electron-builder 配置即可 | Windows 和 Linux 的 locales 目录通常几十 MB，但大部分应用只需要一种语言 |
| 使用 UPX 压缩可执行文件 | 30–50% 的可执行文件体积 | 中等，可能触发杀软误报 | Windows 下对 .exe 和 .dll 进行压缩，但可能影响启动速度并引起安全软件报警 |
| 剔除不必要的 Node.js 原生模块依赖 | 视情况数 MB 到数十 MB | 低，通过 package.json 和打包工具控制 | 检查 node_modules 中哪些库根本没用到 |
| 使用 asar 打包并压缩 | 编码后体积小幅减小 | 低，electron-builder 默认开启 | asar 本身不压缩，但可以结合 upx 或其他压缩；通常不需要额外操作 |
| 延迟加载或按需下载大型资源 | 减少初始安装包体积 | 中等，需要修改代码逻辑 | 例如大文件模板、高清素材、本地数据库文件等，首次启动时从服务端拉取 |
| 移除不必要的二进制文件（如 swiftshader） | 3–10 MB | 低，electron-builder 配置 | 如果你确定目标机器都有 GPU 硬件加速，可以移除软件渲染库，但在老旧设备上可能导致崩溃 |
| 使用 Electron 的 --custom-electron-version 和 nano / slim 分支？ | 理论上可行 | 极高，且不稳定 | 社区有一些裁剪 Chromium 和 Node.js 的尝试，但极易引入构建和维护地狱，不推荐在生产中采用 |

真实案例：一个 Notes 笔记应用在优化前 Windows 安装包 128 MB，通过以下三步操作降到 106 MB：

  1. 删除 locales 中除 en-US.pak 和 zh-CN.pak 以外的所有文件（减少 12 MB）。
  2. 将 10 MB 的高清图标库改为首次启动时下载（减少 10 MB）。
  3. 剔除 node_modules 中未使用的 ffmpeg-static 和 sqlite3 的多平台二进制文件（减少 8 MB，因为打包工具默认会把所有平台的 .node 文件都打进去）。

需要注意的是，这些优化都是锦上添花。如果你硬要把一个 110 MB 的包压到 80 MB，可能会付出异常大的努力，且容易引入稳定性风险。通常能稳定达到 15–25% 的缩减就已经非常不错了。

22.1.4 体积与用户体验的权衡

最后要谈一个更实际的观念：安装包体积在现代网络环境下，对普通用户来说真的那么重要吗？

  • 对于 2025 年的宽带和 5G 网络，下载 100 MB 安装包通常只需要几秒到几十秒，而用户可能根本不会注意到这个大小。
  • 企业内网分发场景下，安装包大小可能影响推送效率，但通常有 CDN 或局域网分发方案缓解。
  • Steam、App Store、Microsoft Store 等分发渠道都有自有的压缩和增量更新机制，用户感知较小。
  • 真正影响用户留存的是“下载完成后能不能立刻流畅运行”，而不是“下载用了 10 秒还是 30 秒”。

许多成功产品（Figma、Discord、Notion）的安装包都在 100 MB 以上，但用户几乎没有抱怨，因为它们的价值远大于那几秒下载时间。如果你的应用功能足够吸引人，体积就不太会成为阻碍；如果你只是一个剪贴板小工具，100 MB 的体积确实会让用户犹豫。所以，对于安装包体积，合理的态度是：首先接受 Electron 应用的“基础体重”，然后在不牺牲稳定性和开发效率的前提下，通过常规配置优化掉明显多出来的部分。

下一节，我们会具体介绍如何通过 electron-builder 的配置来实现上述的语言包裁剪、文件过滤等体积优化操作，并给出一个可以复用的生产配置模板。