当你完成了 Electron 应用的功能开发，接下来的关键一步就是把代码变成用户可以安装、运行的程序。这件事在 Electron 生态中由专门的打包工具来完成。目前有两个最主流的选择：electron-packager 和 electron-builder。它们都能将你的应用、Chromium 运行时和 Node.js 依赖打包成平台特定的可执行文件，但在功能丰富度、配置方式和适用场景上有明显区别。
16.1.1 electron-packager：简单直接的“壳打包”
electron-packager 的历史比 electron-builder 更早，它的职责非常单一：把你的代码和 Electron 二进制文件复制拼装到一起。你可以把它想象成一个智能的“文件复制器” —— 它不做压缩，不生成安装包，不处理代码签名，只是产出一个可以直接运行的目录（macOS 上是 .app 包，Windows 上是包含 .exe 的文件夹）。
基本用法
安装之后，你可以通过命令行直接调用：
npx electron-packager <sourcedir> MyApp --platform=darwin,win32 --arch=x64 --out=dist/或者用 API 方式集成到构建脚本中。可配置的参数包括图标、应用名称、忽略的文件等，都在命令行或 JavaScript 对象中完成。
优点
- 简洁轻量：没有复杂的概念，学习成本极低，几分钟就能上手。
- 透明可控：产出物就是原始文件结构加 Electron 可执行文件，你可以随意修改、压缩或再签名。
- 跨平台打包灵活：可以在 macOS 上同时打包 Windows 版本（需要 Wine 或 Mono 辅助，但可行）。
缺点
- 不生成安装包：你需要额外使用其他工具（如 NSIS、DMG Canvas）来制作安装程序。
- 无自动更新支持：需要自己集成
electron-updater或类似的方案。 - 代码签名需手动处理：macOS 的签名公证、Windows 的签名只能自己写脚本调用系统命令。
- 生态和社区活跃度在下降：更多项目已经转向 electron-builder 或 electron-forge。
即便有这些限制，electron-packager 在需要完全掌控打包过程或者仅需临时分发测试包的场景下依然有用。部分企业级的打包流水线也会把它作为中间步骤，再交由自定义脚本做后续封装。
16.1.2 electron-builder：全能型的“一站式”打包工具
electron-builder 是目前 Electron 生态中事实上的标准打包工具，绝大多数桌面应用的发布流程都依赖它。它不只是“打包”，而是一个集成了编译、代码签名、安装包生成、自动更新、多平台支持的全功能解决方案。
核心能力
- 直接生成平台原生安装包格式：
- Windows：NSIS 安装程序（
.exe）、MSI、便携版 - macOS：DMG、PKG、MAS（Mac App Store）构建
- Linux：AppImage、Snap、deb、rpm 等
- 内置代码签名：macOS 的 Hardened Runtime 签名、公证，Windows 的 Authenticode 签名都可以通过配置完成。
- 压缩与应用资源优化：可以将应用打包为
asar归档文件，加快文件读取速度并减少体积。 - 自动更新支持：与
electron-updater无缝配合，能直接生成latest.yml或latest-mac.yml等更新元数据文件。 - 丰富的配置项：通过
package.json中的build字段或独立的electron-builder.yml文件进行集中管理。
基本配置示例
在 package.json 中：
{
"name": "my-app",
"version": "1.0.0",
"main": "main.js",
"build": {
"appId": "com.example.myapp",
"productName": "MyApp",
"directories": {
"output": "dist"
},
"win": {
"target": ["nsis"],
"icon": "assets/icon.ico"
},
"mac": {
"target": ["dmg"],
"icon": "assets/icon.icns",
"category": "public.app-category.utilities"
},
"linux": {
"target": ["AppImage", "deb"],
"icon": "assets/icon.png"
}
}
}然后运行 npx electron-builder 即可。electron-builder 会自动下载必要的依赖（如 wine、nsis 等）并完成全链路打包。
优点
- 功能覆盖全面：几乎涵盖了从开发到分发的所有需求，自动化程度极高。
- 社区活跃：文档完善，遇到问题容易找到解决方案，主流 Electron 项目都使用它。
- 持续维护：更新频繁，对新版 Node.js 和 Electron 的适配很快。
- 支持多种分发模式：除了标准安装包，还能发布到 Microsoft Store、Mac App Store 和 Snap Store。
缺点
- 复杂度的提高：配置项繁多，新手可能会被大量选项淹没，某些高级功能需要理解其内部机制。
- 打包速度较慢：因为包含压缩、签名、生成多重格式等步骤，完整构建耗时较长（可以通过缓存和增量构建缓解）。
- 对构建环境有一定要求：跨平台打包时可能需要安装 Wine、Mono、fakeroot 等系统依赖。
16.1.3 两大工具对比
| 特性 | electron-packager | electron-builder |
|------|------------------|------------------|
| 定位 | 基础打包，生成可执行目录 | 全流程打包与分发 |
| 产出格式 | 仅可执行文件夹（.app、exe 目录） | 安装包（NSIS、DMG、AppImage 等） |
| 压缩与 asar | 不支持，需手动操作 | 内置 asar 打包，可选压缩 |
| 代码签名 | 无内置，需自己写脚本 | mac/win 自动签名配置 |
| 自动更新支持 | 不直接提供 | 与 electron-updater 深度集成 |
| 配置复杂度 | 低，命令行参数为主 | 中高，配置文件驱动 |
| 学习成本 | 几分钟 | 几小时到一天 |
| 社区推荐度 | 较少使用 | 官方和社区首选 |
| 适用场景 | 简单原型、内部工具、需自定义二级打包 | 商业应用、需要安装包和自动更新 |
16.1.4 如何选择
对于今天的绝大多数 Electron 项目，直接选择 electron-builder 是更省心、更稳妥的做法。它涵盖了从开发到上线的完整流程，而且社区中大量的启动模板（如 electron-vite、electron-react-boilerplate）都已经预置了它的配置，你可以直接开箱即用。
只有在以下特殊情况下，你才可能考虑 electron-packager：
- 你只需要快速给测试人员一个可直接运行的文件夹，不关心安装体验。
- 你所在的公司有一套完全自研的分发流程，只需要“裸”的打包结果，然后自己处理签名、更新和格式转换。
- 你想完全控制每一个打包细节，不希望有任何“自动化”干扰。
一个实用的建议：即使你选择了 electron-builder，也可以先用 electron-packager 生成一个简单的未压缩版本在本地快速验证，确认程序行为正常后再用 electron-builder 做正式构建。两者并不互斥，可以组合使用。
最后提一下 electron-forge，这是 Electron 官方维护的整合工具，内部集成了 electron-packager 并增加了脚手架、发布等生命周期管理。如果你是从零开始的新项目，也可以评估 electron-forge，它试图提供一个更“标准化”的体验。但就纯粹的打包与安装包生成能力而言，electron-builder 依然是功能最强、最成熟的选择。