安装包与更新器：dmg、MSIX、AppImage 与增量更新的验收

安装包是用户见到的第一个界面，更新器是他们之后每天都会遇到的那个。

一、更新到一半，应用打不开了

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

阮宁的桌面笔记工具支持自动更新。某次发布会后第三天，一位用户来信：更新时笔记本休眠，再打开应用就闪退，卸载重装才恢复。

他检查后发现，更新器先把旧版本目录删掉，再解压新版本。中间断电，目录里既没有旧版也没有完整的新版。

同一个版本还暴露了另外两个问题：Windows 用户覆盖安装后，开始菜单里出现了两个图标；Linux 用户下载 AppImage 后没有执行权限，双击毫无反应。

三个问题都不属于功能缺陷，全部来自交付环节。安装与更新是唯一一类「失败即无法自救」的功能：用户没有界面可以点，也没有日志可以看。

二、格式矩阵：每个平台只留一两种

格式不是越多越好，每一种都要长期维护。

macOS 优先 dmg。 拖拽安装符合用户习惯，代价是必须完成签名、公证与装订三件事；pkg 只在确实需要写系统位置时使用。

dmg 的体验细节决定第一印象。 背景图、窗口大小与 Applications 快捷方式的位置，都会影响用户是否拖对；这些细节不写进自动化测试，只能人工看。

Windows 的 exe 安装器覆盖面最广。 需要企业分发时再补 MSI 或 MSIX，不要一开始就同时维护两套。

MSIX 的约束要提前试。 它要求声明能力与打包结构，某些旧组件无法直接放入；先做一个最小包验证，再决定是否走这条路。

Linux 先用 AppImage 验证需求。 它能让你在没有仓库维护成本的情况下交付；用户规模起来后再考虑 deb 与 rpm。

格式数量直接影响发布工时。 每增加一种格式，就多一条构建、签名、验收与文档路径；一个人的产品，三种以内比较可控。

每多一种格式，文档也要多一份。 安装步骤、系统要求与卸载方式都不同；维护成本不只在构建，也在用户看到的说明。

三、安装、卸载与首次启动

安装包的验收不止「能不能装上」。

安装路径要可预测。 用户目录与系统目录的选择，决定了是否需要提权，也决定了卸载时能不能清干净。

权限请求要尽量后置。 安装时索要管理员权限，会劝退一部分用户；能装在用户目录的，就不要装到系统目录。

卸载残留要在设计时就考虑。 配置文件放在用户目录是合理的，但要在卸载时询问是否保留；不询问又不清理，重装后会出现「旧配置生效」的怪问题。

首次启动要给明确反馈。 双击后三秒没有任何窗口，用户会认为程序坏了；至少显示一个启动画面或托盘图标。

启动失败要能自助排查。 提供日志位置与「以安全模式启动」入口，比让用户发邮件等回复更快。

覆盖安装是最容易出问题的路径。 大多数用户不是全新安装，而是从上一版升级；验收必须包含「装过旧版再装新版」。

四、更新器必须通过的六项验收

自动更新是交付链路上风险最高的部分，因为它在你无法观察的机器上修改文件。

六项验收
  1. 清单签名：更新清单与安装包都验签
  2. 版本比较：语义化版本与构建号同时判断
  3. 下载校验：校验和或签名不匹配即中止
  4. 原子替换：先写临时目录，成功后切换
  5. 失败回退：任一步失败保留旧版本可启动
  6. 手动兜底：提供官网下载与离线安装包

清单必须签名。 更新器从网络读取「最新版本在哪」，这条信息若可被篡改，等于把安装权交给第三方。

校验和要放在下载页。 放在发布说明深处，等于没有；与下载按钮同一屏，才会被真正使用。

版本比较要同时看版本号与构建号。 只比版本号，回滚版本会被判定为「不是更新」；只比构建号，跨分支发布容易错序。

原子替换是底线。 直接覆盖安装目录，任何中断都会留下半损坏状态；先解压到临时目录、校验通过后再切换，才能保证「要么旧版，要么新版」。

失败要能退回旧版。 更新失败后应用仍能用旧版启动，用户才有机会重试或联系你；否则只剩卸载重装一条路。

必须保留手动下载入口。 自动更新在受限网络、代理与企业环境中经常失败；官网的离线安装包是最后一道兜底。

手动兜底要包含卸载说明。 自动更新失败的用户，往往也需要先卸载再装；只给安装包，问题仍会回到客服。

五、行动清单与复算验收

• 为每个平台选定一到两种格式，写明放弃其余格式的理由
• 验收全新安装、覆盖安装、卸载重装三条路径
• 检查安装路径、快捷方式、开机启动项与文件关联
• 验证卸载后的残留，并决定是否保留用户配置
• 为更新清单与安装包分别做签名与校验
• 实现临时目录解压与原子切换，验证中断后仍可启动
• 保留官网站载的离线安装包与历史版本
• 在 x64 与 arm64 两种架构上各跑一遍安装与更新

验收标准：在更新过程中强制中断，应用仍能用旧版本启动。 做不到这一条，自动更新就是一次单程旅行。

增量包占比 = 增量包体积 ÷ 全量包体积

示例：全量 120MB，增量 18MB，占比 15%
若月活 2000、月更一次，可节省约 204GB 下载流量

每格式年维护工时 = 每版打包与验收分钟 × 年发版数 ÷ 60
超过 40 小时的格式，应评估是否停用

使用边界与实操验收

本文只讲安装包与更新器的工程验收，不涉及签名与公证的具体操作，那属于第 02、03 篇；版本节奏与回滚决策属于第 09 篇；跨平台构建矩阵属于第 05 篇。

浏览器扩展的更新与回滚属于Chrome Web Store 上架：账号、Manifest V3、权限说明与审核拒绝复盘 ；发布产物的归档与找回属于代码与仓库：多远程、组织所有权、镜像与归档 。

本文也不主张「所有产品都要做增量更新」。下载量小、包体不大的产品，全量更新更简单，也更容易排查问题；只有当下载成本或失败率成为真实痛点时，增量才值得。

验证以安装成功率为准：发布后一周，统计更新失败上报数与手动下载次数。失败率高于 1%，优先检查原子替换与网络重试，而不是归因于用户环境。

关键参考与核验范围

本文的格式对比与阈值为教学演示，实际参数请以各项目文档为准。核验日期：2026-10-24。

• electron-builder ：Electron 应用的打包、签名与自动更新配置文档。
• Tauri Updater ：Tauri 的更新器插件说明，含签名校验与更新清单格式。

上述两条只用于说明公开文档入口，不构成对任何框架的推荐。打包工具的行为随版本变化，发布前请以所用版本的文档为准。

系列导航

• 上一篇：Windows 签名与 SmartScreen：OV、EV 与信誉积累怎么选
• 下一篇：跨平台构建矩阵：三系统两架构的 CI 成本与发布前置时间
• 回到目录：一个人把软件交付到用户手里：签名、安装、更新与审核
• 相关阅读：代码与仓库：多远程、组织所有权、镜像与归档 、Chrome Web Store 上架：账号、Manifest V3、权限说明与审核拒绝复盘