Electron 更新与自动更新：发布渠道、版本与安全

桌面应用的一大工程挑战是「如何持续更新」：不同平台的安装包、版本分发、增量更新、安全校验等问题叠在一起，很容易把发布链路搞得又慢又脆。
这一篇聚焦 Electron 应用的更新体系，从工程视角拆开几件事：有哪些常见的发布方式、自动更新大致怎么运作，以及在版本与安全上需要注意什么。

在讨论更新前，先看安装方式，因为更新链路往往与之强绑定：

  • 传统安装包
    • Windows：exe / msi（如 NSIS、Squirrel.Windows、MSIX 等）；
    • macOS：dmg / pkg / zip；
    • Linux：AppImage / deb / rpm 等。
  • 应用商店渠道
    • Microsoft Store、macOS App Store、各类 Linux 发行版仓库；
    • 商店负责一部分签名与更新逻辑。
  • 自建分发服务
    • 自己的下载站点或 CDN，提供安装包与更新文件；
    • 需要自行处理版本管理与校验。

Electron 本身不强制某一种方式，但会影响后面自动更新可以采用的方案：

  • 使用 electron-builder、electron-forge 等工具时，通常会推荐/集成某种更新流。
  • 在应用商店内分发时，一部分更新机制由商店接管。

2. 自动更新的基本思路：客户端拉取「更新信息 + 更新包」

不管使用哪种具体库，自动更新的一般思路都是：

  1. 应用启动或定期检查时，请求某个更新服务端点；
  2. 服务端根据当前版本、平台、渠道返回：
    • 是否有新版本；
    • 更新内容描述；
    • 更新包下载地址（全量或增量）；
  3. 客户端下载更新包：
    • 部分方案支持静默下载，等待下次重启时应用；
    • 部分方案需要用户确认后再进行。
  4. 验证包的完整性与签名，应用更新：
    • 解压/替换已有安装内容；
    • 或者调用底层更新工具完成升级。

Electron 生态中常见方案（如 electron-updater）本质上做的就是这几步，只是帮忙处理了平台差异、差分更新与签名校验等细节。

在多环境、多渠道的项目里，更新策略往往需要更细的控制：

  • 多渠道
    • Stable / Beta / Canary；
    • 内测渠道 vs 公开渠道；
    • 企业私有部署 vs 公有云版本。
  • 版本兼容性
    • 后端接口与前端应用的兼容策略（向后兼容 vs 强制更新）；
    • 某些版本需要「强制升级」以修复安全问题或重大 bug。

工程实践中常见的做法是：

  • 在更新服务端维护「渠道 → 最新版本信息」表；
  • 客户端上报：
    • 当前版本号；
    • 所属渠道；
    • 所在平台（Win/macOS/Linux）；
    • 可选的用户分组信息（A/B 测试等）。

更新服务根据这些信息返回：

  • 是否建议升级；
  • 是否必须升级；
  • 对应的安装/更新包链接与校验信息。

更新链路一旦被攻击者控制，后果比普通 API 被攻击严重得多：
一次成功的供应链攻击可能让所有客户端安装恶意版本。

安全层面需要注意几件事：

  • 签名与完整性校验
    • 对安装包与更新包进行签名（如 Windows 代码签名证书、macOS 签名与 notarization）；
    • 在客户端严格验证签名与哈希值，防止中间人攻击或篡改。
  • 更新服务的访问控制
    • 使用 HTTPS，避免明文传输更新信息；
    • 考虑为更新服务添加额外的访问控制或限流，防止被滥用。
  • 回滚机制
    • 在发现某个版本存在严重问题时，更新服务应支持快速回退版本信息；
    • 客户端应能正确处理「从较新版本退回到稍旧但稳定的版本」的情况。

在设计更新体系时，建议把「签名与回滚」当成硬性需求，而不是上线后才考虑的附加选项。

更新体验既不能太隐形（用户不知道发生了什么），也不能太打扰（频繁弹窗阻断工作流）。
可以从几个维度平衡：

  • 检查时机
    • 启动时 vs 后台定期（例如每天一次）；
    • 大版本更新可以在启动时提示，小版本补丁可以更靠后台。
  • 下载策略
    • 可行时使用静默下载，等用户空闲或下次重启时应用；
    • 网络条件不佳或包较大时，提供「暂不更新」选项。
  • 反馈与可控性
    • 清晰地展示版本号与更新内容概要；
    • 提供手动检查更新入口，让用户有控制感。

在多端共存的生态里，还需要考虑：

  • 不同平台是否同步推出更新；
  • 某些平台是否采用商店渠道，更新节奏略有不同。

从架构角度看，Electron 应用的更新体系更适合被当成一个独立子系统来设计：

  • 前端（Electron 客户端）负责：
    • 检查更新、下载、校验与应用更新包；
    • 提示用户、处理重启与状态迁移。
  • 更新服务端负责：
    • 版本与渠道管理；
    • 存储与分发安装/更新包；
    • 回滚与审计。

当更新这一块有了清晰的分层和策略之后，Electron 应用可以在保证安全的前提下，做到「稳定地持续演进」，而不是每次升级都像一次「重新安装一个新应用」。