6.1 打包工具对比：electron-builder 与 electron-forge

6.1 打包工具对比：electron-builder 与 electron-forge

本节摘要：electron-builder 以配置丰富、产物形态全见长，Electron Forge 以官方血统、流程整合见长，两者都覆盖打包到安装包的完整链路。本节对比两者的真实差异（配置风格、平台产物、更新集成、生态资料），给出选型判据，并展示一份可直接套用的 builder 配置解读与 Forge 的等价思路。

两条主流路线

打包环节的问题清单是固定的：把 Electron 运行时与应用资源组装成产物，再包装成各平台的安装包（安装器格式、开始菜单/快捷方式、卸载信息），顺手处理图标、版本号、自动更新的元数据。两条主流路线对这些问题的回答风格迥异。

electron-builder：社区出身，后成为事实标准。特征是"一个配置文件管全部"——三平台的产物形态（Windows 的安装器、macOS 的镜像包、Linux 的各类包格式）声明式配置，产物命名规则、更新元数据、差量更新的底层支持一应俱全。优点是成熟度高、遇到的坑几乎都有前人答案；代价是配置项繁多，某些行为隐晦（自动推断、平台特例），出问题时要翻文档深处。

Electron Forge：官方钦定的工具链。特征是"流程整合"——初始化、开发、打包、发布（对接 GitHub Releases 等渠道）一条命令贯穿，模板化起步快。优点是血统纯正、与新版本 Electron 的适配总是第一时间；代价是复杂定制场景的灵活度不如 builder，个别平台产物形态要靠模板扩展。

选型判据很朴素：要极致的可定制与多产物形态，选 builder；要官方工作流与发布渠道整合，选 Forge。已有项目跟着存量走，别为换工具而换。

读一份 builder 配置

builder 的配置集中在 package.json 或独立配置文件里，读懂一份典型配置，打包的基本盘就清楚了：

{
  "appId": "com.example.myapp",
  "productName": " MyApp",
  "directories": { "output": "release" },
  "files": [
    "dist/**/*",
    "build/icon.*"
  ],
  "asar": true,
  "win": {
    "target": ["nsis"],
    "icon": "build/icon.ico"
  },
  "nsis": {
    "oneClick": false,
    "allowToChangeInstallationDirectory": true
  },
  "mac": {
    "target": ["dmg"],
    "category": "public.app-category.productivity"
  },
  "linux": {
    "target": ["AppImage", "deb"],
    "category": "Utility"
  }
}
​

几个字段值得展开。files 白名单决定哪些文件进安装包——只带产物目录与图标，源码、测试、开发配置全部排除，这是体积控制的第一道闸（6.4 节展开）。appId 与 productName 是应用在操作系统层面的身份标识，一旦发布就不要改，改了等于换了一个应用（更新通道、卸载记录、权限关联全部断裂）。三平台 target 各自声明产物形态：Windows 选安装器类型（nsis 是常见选择，可配置安装目录；一键安装的体验见仁见智），macOS 通常出镜像包，Linux 按用户群出通用格式或发行版包。

Forge 的等价思路是配置里的打包器与发布器组合：本地打包用内置打包器，发布器对接代码托管平台的发布页，命令行一条龙完成。两条路线殊途同归：产出可安装、带身份、可更新的应用。

图：两条工具路线的管线对比

案例：一个团队的选型迁移

背景：一个中型团队的老项目用 builder，配置滚了三年，复杂度可观：四平台九种产物、定制安装界面、特殊目录逻辑。新加入的负责人主张迁 Forge"回归官方"，团队做了评估。

操作：评估按两步走。先列需求清单——逐项标注"必须保留"（九种产物里的五种实际有人用吗？调研发现三种零下载，可裁）、"可以妥协"、"必须放弃"。再用 Forge 起原型——把"必须保留"项在 Forge 里逐个验证，结果定制安装界面与一种特殊产物格式在 Forge 模板体系下实现代价高。

结果：决定不整体迁移，而是"瘦身不动骨"：builder 配置删掉三种零下载产物与两套废弃逻辑，配置文件瘦身一半；新开的子项目用 Forge 起步。两套并存但各有定位。

解读：这个案例展示工具选型的成熟姿态——选型服务于需求清单，而不是信仰。"官方 vs 社区"的争论不如"我的产物矩阵到底需要什么"来得实际。变式：如果是全新项目、产物需求常规、发布渠道就在代码托管平台，Forge 是省心的默认解；反之涉足安装器深度定制，builder 的存量生态就是生产力。

本节要点回顾

• 两条路线：builder 声明式全管、Forge 官方流程整合，覆盖面各有侧重；
• 身份字段：appId 与 productName 发布后不可改，改了等于换应用；
• files 白名单：只带产物与图标，是体积控制第一道闸；
• 选型判据：重定制选 builder、官方流选 Forge，存量项目不折腾；
• 评估姿势：需求清单先行，零下载产物果断裁撤。 裁撤的勇气来自数据而非感觉：产物下载统计要看渠道口径（官网直链、更新器拉取、镜像分发分别统计），至少观察一个完整的大版本周期再下结论——有些产物是季节性的（企业客户季度集中安装），样本期太短会把活着的产物裁成尸体。

工具定了，下一节处理远行途中最硬的一关：三平台构建差异与代码签名的信任链。