31. 打包概述与工具选择：Forge 还是 Builder

本节目标

理解「打包」在 Electron 流程里的位置。
对比 Electron Forge 与 electron-builder 的配置方式。
了解两者的插件体系与生态差异。
明白官方文档为什么主推 Electron Forge。
根据自身情况做出工具选择。

1-1 打包到底做什么

Electron 应用开发时，靠 electron . 启动的是源码。要交给用户，必须把「你的代码 + Electron 运行时 + 系统适配」打包成可分发的安装包或可执行文件，比如 Windows 的 .exe/.msi、macOS 的 .dmg/.app、Linux 的 .deb/.rpm/AppImage。

这一步叫打包（packaging），产出的东西称为「可分发包（distributable）」。Electron 核心本身不包含打包工具，必须借助外部工具完成。

打包通常涉及三件事：把代码与 Electron 二进制捆在一起、按平台生成对应格式、对产物做代码签名。自动更新（上一章）则建立在打包产物之上。

1-2 两个主流工具

社区里最主流的打包工具有两个：Electron Forge 与 electron-builder。它们目标相同，但理念与结构差异明显。

Electron Forge 是 Electron 官方文档中推荐的一站式工具，它把 @electron/packager、@electron/osx-sign、electron-winstaller 等底层工具统一到一个接口之下，让你不必自己拼接链路。

electron-builder 是社区中非常流行的第三方方案，以「配置即所得」著称，一份配置就能产出多平台安装包，并自带 electron-updater 做自动更新。

本书主线采用官方推荐的 Electron Forge；electron-builder 仅在此作为对比参考。

1-3 配置方式对比

Electron Forge 用独立的 forge.config.js 描述构建。它把「生成哪种包」拆成 makers，「发到哪」拆成 publishers，「额外集成」拆成 plugins，结构清晰、职责分明。

// forge.config.js（Electron Forge）
module.exports = {
  packagerConfig: {
    asar: true
  },
  makers: [
    { name: '@electron-forge/maker-squirrel' },
    { name: '@electron-forge/maker-dmg' },
    { name: '@electron-forge/maker-deb' }
  ],
  publishers: [
    { name: '@electron-forge/publisher-github', config: { repository: { owner: 'me', name: 'app' } } }
  ]
}

electron-builder 习惯把配置写在 package.json 的 build 字段，或单独的 electron-builder.yml 里。它用 targets 描述产物，单文件配置更紧凑，上手更快。

# electron-builder.yml（第三方方案）
appId: com.example.app
productName: MyApp
directories:
  output: dist
files:
  - "out/**/*"
win:
  target: nsis
mac:
  target: dmg
linux:
  target: deb

1-4 插件与生态对比

Electron Forge 的插件体系是其强项。官方提供了 @electron-forge/plugin-webpack、@electron-forge/plugin-vite 等，能把前端构建直接并入打包流程；makers 与 publishers 也是插件化的，按需安装。

electron-builder 生态同样成熟，社区模板丰富，支持的打包目标非常广（NSIS、AppX、Snap、Flatpak、AppImage 等），并且内建 electron-updater，对「打包 + 更新」一体化需求很友好。

粗略对比：Forge 更贴近 Electron 官方脉络、插件模型一致；electron-builder 配置更轻、目标格式更全、更新集成开箱即用。

1-5 为什么官方推荐 Forge

Electron 官方教程（Packaging / Publishing and Updating）全程以 Forge 为示例，从 npm create electron-app 起步，到 electron-forge make、electron-forge publish 一条龙。选择与官方文档一致的工具，意味着你遇到的大部分问题都能在官方文档里找到对应答案。

Forge 的另一优点是「组合而非重写」。它站在 @electron/packager 等久经考验的工具之上，行为可预期，升级 Electron 时踩坑概率更低。

对于刚入门、希望路线与官方同步的读者，Forge 是更省心的默认选择。下一章会带你用 Forge 真正打包出一个应用。

1-6 如何选择

如果你的场景符合以下任一点，优先考虑 Electron Forge（推荐）：

希望路线与 Electron 官方文档一致，降低学习成本。
使用 webpack / Vite 等前端构建，想和打包流程打通。
需要把产物自动发到 GitHub Releases。

如果更符合以下情况，可以评估 electron-builder：

想要单份配置产出尽可能多的平台安装格式。
已经依赖 electron-updater，希望打包与更新一体。
团队已有 electron-builder 模板与经验。

无论选哪个，底层能力是相通的：都要解决平台差异、代码签名、asar 打包、自动更新集成。工具只是把这些步骤封装起来的方式不同。

1-7 一张速查对照表

为了更直观，下面把两者放在一张表里对照。它不评价优劣，只呈现差异，帮助你按团队情况判断。

维度	Electron Forge	electron-builder
官方推荐	是（文档主线）	否（社区方案）
配置位置	`forge.config.js`	`package.json` 或 `electron-builder.yml`
扩展方式	makers / publishers / plugins	targets / 内置配置
前端集成	官方 webpack、Vite 插件	多数自行接入
自动更新	内置 `autoUpdater` + `update-electron-app`	自带 `electron-updater`
学习曲线	概念稍多但和官方一致	上手快、配置紧凑

这张表说明：Forge 胜在「与官方同路、插件模型统一」，electron-builder 胜在「配置轻、目标全、更新一体」。对于本教程读者，默认走 Forge 即可，后续章节也以它为准。

还有一个常被忽略的点：打包通常会把源码打进 asar 归档。它本质是一个只读的归档格式，能加快加载、隐藏源码结构，但某些原生模块或需动态读取的文件要从 asar 中解压出来。无论用哪个工具，都要理解 asar 的取舍，必要时在配置里声明 asarUnpack。

如果你是从 electron-builder 转到 Forge，迁移成本主要是配置重写与发布脚本调整，业务代码不受影响。两者产出的最终安装包在用户眼里并无差别，工具选择更多是团队偏好与维护成本的问题，不必过早纠结。

回到本教程的立场：我们以 Electron Forge 为主线，不是因为它功能碾压对手，而是因为它与官方文档、官方示例、官方更新服务天然对齐。对入门读者而言，这条「官方同路」能让你在搜索报错、阅读教程、升级版本时都更顺，少走弯路。

当然，工具会演进，electron-builder 也仍在广泛使用中。掌握其一后，理解另一个并不难，因为它们的核心都是「捆代码、出安装包、做签名、接更新」。先把 Forge 这条路走通，再横向了解其他方案，才是稳妥的学习顺序。

常见误区

不要把「打包」和「发布」混为一谈。打包生成安装包，发布是把安装包传到仓库或服务器，两者在 Forge 里分别是 make 与 publish 两步。

不要以为选了工具就无需理解平台差异。不同系统的安装包格式、签名要求各不相同，工具只是帮你执行，前提仍是你提供正确的配置与证书。

不要因为 electron-builder 流行就忽视官方推荐。对初学者，与官方文档同路的 Forge 能显著减少「文档对不上」的困扰，本书后续打包章节均以 Forge 为主线展开。