桌面自动更新失败后，残留进程与失败状态应该怎样处理

关联案例：AI Agent 应用平台。文章依据本地 Tauri 更新服务的控制流程整理；示例去掉了业务命令名与端点，只表达停止、安装、重启与回退的顺序。本文不声称某次线上事故已完成自动恢复。

更新不是“下载完成”

自动更新往往被理解成：检查版本 → 下载 → 安装 → 重启。真正容易出问题的是夹在中间的本地状态：

应用自己还在跑，安装包要覆盖正在占用的文件；
更新前启动的本地服务（MCP、网关、辅助进程）可能占着端口或目录；
下载或安装失败后，界面若只显示“更新失败”，用户无法判断旧版本是否还能用；
Windows 上还可能留下未退出的残留进程，导致下次启动仍指向旧资源。

所以先把问题收窄：失败时，系统是否留下可解释、可继续使用的状态？

更新前先显式停掉会抢资源的进程

本地更新服务在调用安装之前，会先停止自己拉起的辅助服务，并记录“已经停过”。这样做的目的不是“更干净”，而是：

减少安装时文件被占用的概率；
失败后知道应该恢复哪些进程，而不是盲目重启整机应用。

检查更新 ─→ 停止本地服务（记录 stopped） ─→ 下载/安装
                                              │
                         失败 ←───────────────┴───────────────→ 成功 relaunch
                           │
                           └─ 按 stopped 记录恢复服务，再给出可操作提示

顺序不能反：先安装再停服务，残留进程更容易和安装器抢同一目录。

失败分支要区分，而不是统一“出错了”

值得分开处理的至少有三类：

失败点	用户需要知道什么	界面不应做什么
检查更新失败	网络或端点问题，旧版本仍可用	不要暗示已有新版本
下载/安装中断	是否已写入部分文件，是否需要重试	不要自动重启到半成品
安装成功但未重启	新版本已就位，需要手动确认重启	不要静默强杀未保存工作

本地实现里，Tauri Updater 检查失败时会降级到“打开安装包下载链接”的手动路径；这不是两套更新策略并存，而是同一次意图下的回退，且回退前仍要恢复已停止的服务。

版本号不能代替进程状态

界面显示“已是最新”只能说明版本比较通过，不能证明：

上次更新的辅助进程都已退出；
临时目录或 _up_ 类升级目录已清理干净；
当前窗口加载的前端资源与可执行文件版本一致。

因此失败提示应尽量带上可核对信息：当前版本、目标版本、失败阶段、是否已停止本地服务。排查时先看这些字段，再决定是重试、手动安装，还是清理残留进程后冷启动。

验证更新失败，而不是只测成功升级

成功路径几乎总能通过。更值得补的用例是：

检查接口超时：保持旧版本可用，明确错误文案；
下载中断：不触发重启，恢复已停止的服务；
安装被占用文件拒绝：提示关闭占用方，而不是循环静默重试；
身份切换或强制重连场景下的窗口恢复：更新完成后页面状态可重建。

自动更新的可靠性，首先体现在失败后用户仍知道应用处于哪一种状态，其次才是能否一键装上新版本。