Qt6 Host + Updater 更新方案(1)：整体流程与交互设计

你有没有遇到过这种尴尬：软件提示“有新版本”，点了更新却失败；或者更新到一半程序直接卡死；再或者最常见的——Windows 下主程序正在运行，EXE 被占用，根本没法覆盖替换。

很多 Qt 新手第一次做在线升级，都会卡在这些坑里：占用文件无法替换、权限不够（UAC）、下载中断、更新失败后怎么恢复、更新完成后怎么自动重启……

这套专栏我会用一个“可跑通的 Demo”把这些问题一次讲清楚：主程序（Host）只负责检查并触发更新，真正的替换工作交给独立的更新器 AppUpdater.exe 来做。这样才能安全替换旧程序、更新完成自动重启，整个流程稳定、可控、可扩展。

在进入实现细节之前，先明确整个流程的分层与边界。此时分为两段：

★ 感知更新（Check）

启动后静默获取 manifest.json，进行版本比较，并更新 UI（例如升级按钮 Badge/“升级”标识）。该阶段不下载更新包、不退出宿主、不做文件替换。

★ 执行更新（Apply）

用户点击升级后，由 AppUpdater.exe 接管下载与安装；下载完成后关闭宿主，再进行文件替换与重启。

关键设计原则可以归纳为三点：

1）职责解耦：Host 只负责“发现与触发”，Updater 负责“执行与落地”。

2）不打断体验：启动仅提示，安装由用户确认触发；下载完成后再关闭宿主。

3）可恢复/可诊断：下载校验、替换原子性、失败回滚与日志记录缺一不可。

因此，第一张流程图从“感知更新”开始：宿主启动时的静默检查与 UI 标记流程。

感知更新

目的

宿主启动后在后台静默检查是否存在新版本，并将结果映射到UI（例如：升级按钮上是否存在升级标识）。该阶段只负责“提示”，并不触发升级执行。

边界

该阶段只做轻量检查，不下载更新包、不关闭宿主进程、不进行任何文件替换操作、不改变当前运行环境。

真正的下载与替换在用户点击升级后由独立更新器AppUpdater.exe执行。

执行更新

目的

用户点击升级入口后，由独立更新器AppUpdater.exe完成下载、校验、解压、关闭宿主、资源替换、重启宿主（在这里未曾设计并实现回滚操作），确保更新过程稳定且可恢复。

关键策略

1：下载可取消

下载阶段允许用户取消；取消应停止请求并清理临时文件，避免残留半包影响下次升级。

2：完整性校验

下载完成后必须进行hash/size校验（manifest提供），校验失败应提示重新下载。

3：staging预备

先解压到staging目录，带宿主退出后再一次替换，缩短停机时间。

4：退出策略

优雅退出优先（通知宿主自行关闭并等待）；超时后提示用户手动关闭，必要时提供强制结束进程。

结语

本文完成了 Host+Updater 更新流程的全景梳理，并明确了 Check/Apply 两阶段的边界与关键分支处理。

接下来要解决的是：流程中的“数据从哪里来”。无论是启动提示更新，还是 Updater 下载与校验，核心都依赖 manifest.json。

所以下一篇将聚焦 manifest 设计：字段约定、版本比较规则、完整性校验以及强制更新策略，给出一份可直接用于 Demo 的 manifest 示例。

我是糯诺诺米团，一名C++程序媛~