一个 Electron 应用开发完成后，最终要交付给不同操作系统的用户。打包过程本身的复杂度，往往不亚于功能开发。这一节将从实战角度出发，梳理三种主流的多平台打包方案：本地打包、CI 云打包和跨平台编译，帮你根据团队情况选择最合适的策略。
16.4.1 本地打包：最直接的起步方式
本地打包就是在你自己的开发机上，直接运行打包命令生成安装包。它的优势是简单、快速、门槛低，适合个人开发者或小团队早期阶段。
操作步骤：
- 确认开发环境：本地开发机已经完整安装了 Node.js、npm 和相关原生编译工具（Windows 需要 Visual Studio Build Tools，macOS 需要 Xcode Command Line Tools，Linux 需要 build-essential）。
- 配置打包工具：最常见的是 electron-builder，在
package.json或独立的electron-builder.yml中填写应用名称、图标、平台特定设置。 - 执行打包命令：比如
npx electron-builder --win生成 Windows 安装包，--mac生成 macOS 安装包，--linux生成 Linux 包。 - 检查产物：在
dist目录下找到生成的.exe、.dmg或.AppImage文件，直接在本地进行安装测试。
局限与适用场景：
本地打包最大的限制在于操作系统绑定。你只能在自己当前的操作系统上打包对应平台的产物。如果你想在 macOS 上同时生成 Windows 的 .exe，就必须依赖额外的跨平台编译能力（后面会详述）。因此，纯本地打包更适合只需要覆盖单一平台或最多两个平台的初期项目。
另外，本地打包的环境容易被“污染”：依赖版本、系统工具链、临时文件都可能影响构建结果。如果某次打包成功，下一次突然报错，往往是因为本地环境发生了不可追踪的变化。这时，更需要一种标准化的打包环境——这就是 CI 云打包的作用。
16.4.2 CI 云打包：标准、稳定、自动化的首选
CI（持续集成）云打包是目前最为推荐的打包方式。它将打包过程从开发者本机迁移到云端虚拟环境，每次打包都在一个干净、可复现的操作系统镜像中执行，彻底消除了“在我机器上能跑”的问题。
常用方案：
- GitHub Actions：开源项目免费额度充足，支持 macOS、Windows、Linux 三种 Runner。可以直接使用社区现成的 action，比如
samuelmeuli/action-electron-builder，几行配置就能实现推送代码后自动构建全平台安装包。 - GitLab CI / Jenkins：适合自建 CI 的团队，同样可以通过 Docker 或物理机配置多平台构建节点。
- AppVeyor / Travis CI：老牌 CI 服务，对 Electron 打包也都有成熟的支持。
一个典型的 GitHub Actions 多平台打包配置片段：
name: Build
on: push
jobs:
release:
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: 18
- run: npm ci
- run: npx electron-builder --publish=never
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- uses: actions/upload-artifact@v3
with:
name: ${{ matrix.os }}
path: dist/*这个工作流会在每次代码推送时，同时在三台虚拟机（Ubuntu、macOS、Windows）上执行构建，生成对应的安装包并上传为制品。整个过程中开发者不需要碰任何本地环境，只需要提交代码即可。
云打包的核心价值：
- 环境一致性：所有构建都在相同的操作系统镜像上执行，出现的错误都是可复现的，便于排查。
- 自动化与解耦：打包不再依赖某个成员的电脑，离职、换电脑都不会影响发版流程。结合自动更新和版本管理，可以做到“一键发布”。
- 并行加速：三平台同时构建，大幅缩短总打包时间。对于大团队，更可以结合缓存加速依赖安装，进一步提升速度。
如果你所在团队有跨平台发布的需求，但开发主力都使用 Mac，那么 CI 云打包是最经济高效的选择——你们不需要采购 Windows 或 Linux 物理机，所有操作系统都由云端提供，按使用计费（开源项目基本免费）。
16.4.3 跨平台编译：在单一系统上生成全平台包
有时出于各种原因（网络限制、CI 成本、安全策略），你可能需要在本地生成所有平台的安装包，即便你只用一台 Mac 或一台 Windows 开发机。这时就需要跨平台编译能力。
实现原理：
electron-builder 可以利用一些技术手段，在某个操作系统上为其他操作系统生成安装包：
- macOS 上打包 Windows：electron-builder 会下载 Windows 版本的 Electron 二进制文件，并通过
wine或mono模拟器运行 Windows 下的 NSIS 安装程序生成逻辑。需要在 macOS 上额外安装wine和mono（brew install wine mono）。 - macOS 上打包 Linux：Linux 包的生成相对简单，主要是组织文件和依赖，不需要模拟器。electron-builder 可以直接将文件打包成
.AppImage、.deb等格式。 - Windows 上打包 macOS：理论上也可以，但实际限制较多且不稳定，基本不建议。macOS 包需要在 macOS 环境下签名和公证，否则在用户端无法正常安装或运行。因此通常不采用 Windows 到 macOS 的跨平台编译。
- Linux 上打包 Windows/macOS：同样受限于签名和系统工具链的问题，很少有团队这样做。
实际效果与坑点：
跨平台编译最常用的场景是在 macOS 开发机上生成 Windows 的 .exe。对于简单的测试或内部分发，这种方式确实可以省去 CI 的配置。但你需要明白，通过 wine/mono 生成的 Windows 安装包默认不具备代码签名，用户在安装时会看到 “未经验证的发布者” 警告。如果是正式发布的商业软件，最终仍然需要在一台 Windows 物理机或 CI 上使用有效的数字证书重新签名。
另外，有些依赖了原生模块（如 better-sqlite3、node-pty）的项目，在跨平台编译时可能会因原生模块的二进制兼容性问题而导致打包失败。一种常见解决方案是在不同平台的 CI 环境下重新编译这些原生模块，替代单纯的跨平台打包。
推荐策略：
- 开发阶段：在本地利用跨平台编译快速验证安装包形态，确保 UI 和文件结构无异常。
- 正式发布：务必采用 CI 云打包或专门的实体机（Windows 机、macOS 机）来生成已签名的发布包。签名是通过 Microsoft、Apple 等官方市场或杀毒软件白名单检测的必要步骤，不能绕过。
16.4.4 三种方案的选型建议
你可以根据团队规模、发布频率和安全要求来决定使用哪种打包方案：
- 个人项目或初创小项目：先从本地打包开始，只在自己拥有的操作系统上构建。随着用户增多，再逐步引入 CI 做自动化构建。
- 正式商业产品：CI 云打包是标准答案。设置一次后就能稳定运行，结合版本发布、自动更新、代码签名等步骤形成完整的交付流水线。
- 特殊受限环境：如果无法使用云服务，可以配置一台 macOS 和一台 Windows 物理机作为“打包服务器”，通过局域网触发构建。这种模式虽然属于本地打包的变体，但通过单独维护构建机，也能达到环境隔离和一致性的目的。
无论选择哪种方案，核心原则不变：让打包过程可重复、可追溯、尽可能少地依赖特定开发者的本地环境。只有这样，你的 Electron 应用才能持续、稳定地交付给所有平台的用户。