35. 分发与安装包

应用签名完成后，真正的目标才出现：让用户轻松拿到并安装它。不同操作系统偏爱不同的安装包格式，自动更新则决定了用户是否愿意长期留用。本章梳理主流分发格式、更新机制与体积优化，帮你把应用顺畅交到用户手中。

本节目标

• 认识各平台的主流安装包格式与适用场景。
• 了解 Electron 自动更新的两种实现思路。
• 掌握常见分发渠道与取舍。
• 用几种手段给安装包瘦身。
• 建立「签名是分发前提」的整体认知。

1-1 各平台安装包格式

安装包格式由操作系统习惯决定。选错格式会增加用户门槛，选对应格式则能顺滑安装。

macOS：.dmg 与 .zip。 .dmg 是磁盘镜像，用户拖拽应用进「应用程序」文件夹即可，是最常见形式。.zip 则更轻量，适合内部分发。两者都要求先完成上一章的签名与公证。

Windows：.exe 与 .msi。 通过 Forge 的 maker-squirrel 生成 .exe 安装程序（基于 Squirrel.Windows，支持自动更新）；maker-wix 生成 .msi（企业环境常见，但不自带更新器）。Windows 用户熟悉「下一步式」安装，.exe 体验最佳。

Linux：.deb、.rpm、AppImage、Flatpak、Snap。 这是最碎片化的平台。Debian/Ubuntu 系用 .deb，Red Hat/Fedora 系用 .rpm。AppImage 是单文件、免安装、双击即跑，跨发行版通用，分发最简单。Flatpak 与 Snap 则是沙箱化的应用商店格式，需上架对应仓库。

1-2 自动更新服务

用户装上一次不难，难的是让他们一直用最新版。Electron 的 autoUpdater 模块能让应用后台检测并安装更新，无需用户手动下载。

官方内置的 autoUpdater 依赖一个更新服务器，提供版本清单与增量文件。常见方案有：

• electron-release-server：自建开源更新服务。
• update.electronjs.org：GitHub Releases 驱动的官方托管服务，适合开源项目，零运维。
• electron-builder 的 electron-updater：社区最流行的更新库，支持 GitHub、S3、私有服务器，配置简单（注意它属于 electron-builder 生态，与 Forge 的 autoUpdater 是不同实现）。

无论用哪种，更新服务器返回的元数据必须与本地 app.getVersion() 匹配，且更新文件本身也要签名，否则会被系统拒绝。

1-3 分发渠道怎么选

最直接的方式是把安装包上传到自己的官网或对象存储，生成一个下载链接。这种方式完全可控，但要求你已签名，否则用户会被安全警告劝退。

要触达更多用户，可上架各平台的软件商店：Mac App Store、Windows Store、Snapcraft（Linux）。它们带来流量，但各自要求不同的打包格式与审核，工作量高于直链下载。开源项目则可利用 GitHub Releases 分发，配合 update.electronjs.org 实现免费更新。

选择建议：个人或小团队先做官网直链 + GitHub Releases；有精力再考虑上架商店。不要一开始就被多平台商店的复杂度拖垮。

1-4 安装包体积优化

Electron 应用自带 Chromium 与 Node.js 运行时，安装包天生比原生程序大（常达几十到上百 MB）。以下手段可明显瘦身：

1. 启用 asar 归档。 把源码打进 asar 能压缩体积并加速加载（见第 33 章）。

2. 依赖裁剪（prune）。 @electron/packager 默认只打包 dependencies，忽略 devDependencies。确认 package.json 里测试、构建类依赖都放在 devDependencies，可砍掉大量无用文件。

3. 用 .gitignore / .electronignore 排除文件。 Forge 会读取忽略规则，避免把源码仓库、node_modules 里的文档、测试目录打进安装包。

4. 只打包目标平台。 在对应系统上 make 该平台的包，不要试图一次跨平台构建（Electron 不原生支持交叉编译安装器）。

5. 精简原生模块。 原生模块会带 .node 文件与运行时库，体积可观。能用品纯 JS 实现就避免引入。

1-5 分发前的检查清单

把应用交给用户前，建议逐项核对：安装包是否已签名、macOS 是否完成公证、更新服务器地址是否正确、各平台入口路径是否用 process.resourcesPath 动态获取、.gitignore 是否排除了 out/ 与密钥。

任何一项疏漏都会在用户端变成「打不开」「更新失败」的工单。签名（第 34 章）是这一切的前提。

常见误区

• 认为 AppImage 需要安装。它是单文件免安装格式，双击即运行，但首次需赋予可执行权限。
• 用 .msi 期望自动更新。maker-wix 生成的 MSI 不自带更新器，需自行设计更新流程。
• 忽略体积优化。不裁剪 devDependencies、不打 asar，安装包会虚增数十 MB。
• 未签名就分发。没有签名，macOS 与 Windows 都会强力拦截，用户流失严重。

1-6 更新服务器的注意事项

无论选哪种更新方案，服务端返回的版本清单必须与本地 app.getVersion() 一致，否则 autoUpdater 无法判断是否需要更新。更新文件本身也必须签名，否则系统拒绝应用。对开源项目，update.electronjs.org 配合 GitHub Releases 几乎是零成本方案；闭源或企业内部分发则自建 electron-release-server 更可控。上线前务必在真实网络环境验证一次完整更新链路。

1-7 用户体验细节

分发不只是技术传递，还关乎第一印象。下载页应明确标注各平台安装包与系统版本要求；更新说明写清变更，能降低用户焦虑。即便是小团队，一份清晰的发布说明也比静默更新更赢得信任。把安装包校验和（如 SHA-256）一并公布，也能帮助用户确认下载未被篡改。

小结

本章覆盖了安装包格式、自动更新、分发渠道与体积优化。分发不是「传个文件」那么简单，而是签名、更新、渠道共同构成的最后一公里。下一章我们回到开发期，讲如何用 DevTools 与主进程调试定位问题。