先给当前部署做一份清单
Mihomo版本更新前，记录实际运行程序的完整路径、版本输出、CPU架构、启动参数和配置位置。不要只记录终端PATH中的版本：服务或图形客户端可能调用了另一份文件。还应确定由谁管理进程，以及是否存在自动重启机制，避免手动停止后又被其他工具拉起。
检查所选Release或Alpha的变更说明、已知问题与系统要求，再决定是否升级。并非所有版本都可以无条件覆盖，也不能根据文件名大小判断兼容性。若构建标记发生变化，按发布文件命名与架构说明重新选择，不沿用上一版的下载直觉。
备份的单位是一套可恢复状态
至少保留旧程序、当前生效配置、必要的本地引用资源以及服务单元或启动脚本。确认备份可读取，记录存放位置，并限制其访问权限。配置里可能有凭据，不能因为它是备份就随意上传。客户端托管的核心，还需要了解客户端是否会自动覆盖手动替换的文件。
- 程序：原始压缩包、解压后的可执行文件与版本信息。
- 配置：当前实际加载的文件，以及它依赖的本地资源。
- 运行方式：服务名称、账户、工作目录、参数与必要环境。
- 恢复依据：替换时间、旧文件位置和更新前的正常观察记录。
对候选Mihomo文件进行完整性核对，发布方有可信校验值时按同一算法比较。Windows可使用Get-FileHash，Linux常用sha256sum。单独算出一个散列值只能用于标识文件，不能自动证明其来源。先把候选文件保存在独立目录，不要覆盖正在运行的核心。
停止、替换与验证各有一个确认点
停止之前，确认影响范围
安排维护窗口，用既有客户端或服务管理器正常停止，并确认目标进程退出。受管理的服务不要与手动启动流程交叉使用。Linux环境中服务名称与程序路径，应与服务配置和状态记录一致，不能假定每台设备都叫同一个名称。
替换之后，先验证版本与配置
保留旧文件后再替换为已解压的新程序，检查可执行权限、所有者和路径是否仍符合原部署。查询新Mihomo程序的版本，随后在独立数据目录中使用可信配置副本进行配置有效性检查。不能把旧版检查结果当作新版的兼容保证。
重新运行，观察实际行为
按原有管理方式启动，检查进程、监听和新一轮日志。用原先可复现的请求验证关键功能，并观察是否持续重启。保留更新前后的记录，避免只看到一次进程出现就宣布完成。真实连接验证应以自己的目标环境为准，不编造通用的成功日志。
失败时恢复配套文件，而非只换回程序
若Mihomo新版本出现无法接受的问题，先停止新实例，再恢复旧程序与对应的配置、资源和启动设置。新版本运行期间如果改动过配置，单独换回二进制文件可能仍会失败。恢复后重复检查版本、配置、监听和实际请求，确认原来的管理方式能够继续工作。
回退完成后保存失败现象与版本差异，暂时保留两套文件用于比较；不要在刚恢复时立即删除旧备份。维护记录写清楚“恢复了哪些文件、用什么方式验证”，下一次评估升级就有可靠起点。
