给自动化脚本加失败回滚这步，我踩了三个坑才跑通

最近把手头一套半自动部署流程补了个失败回滚，本来以为加个 if 判断就完事，结果真跑起来翻车三次，记录一下，给同样爱手动控制的兄弟避避坑。

场景：一个批处理 + PowerShell 混写的脚本，干的事不复杂——批量解压部署包、覆盖配置、重启服务。以前没回滚，中间挂了就人工收拾，坏处是收拾时间比写脚本还长。

坑一：回滚点没对齐，等于白留

我最初是在解压前打个包做备份，日志路径、配置目录全塞一起。结果测试时故意中断，回滚一跑，把日志也一起还原了——排查线索全没了。后来改成只备份会被覆盖的路径，日志单独放一个不参与回滚的目录。判断依据很简单：回滚是为了恢复可用状态，不是恢复现场，现场得留着查。

坑二：失败判定太粗，误触发回滚

脚本原来只看退出码，非 0 就回滚。问题是有的命令退出码非 0 但实际是警告，比如服务重启时的超时提示。我拿三台机子对了一遍，发现同一命令退出码稳定但语义不同。现在改成退出码 + 关键输出匹配双条件，两个都命中才回滚，误判率下来不少。

坑三：回滚本身也会失败

这是最要命的。回滚步骤里有个复制操作，磁盘空间不够直接挂在那，脚本以为回滚成功继续往下走。后来加了回滚后的校验——比对文件数和关键文件哈希，校验不过就直接停住并弹告警，不再往下执行。宁可停，也别半死不活。

现在的结构大致是：

1. 预检：磁盘空间、目标路径占用、服务当前状态
2. 打回滚点：只备份目标文件，带时间戳
3. 执行：每步单独 try，失败记录到统一日志
4. 回滚：复制 + 哈希校验，校验失败即中止
5. 收尾：日志归档，不参与回滚

顺便说一句，软领那套自动优化我也装了，图它无广告、不偷偷弹窗，懒人场景确实省事。但它那种一键优化我不太敢用在部署机上——改了什么不透明，出问题不好回溯。我这边还是手动控制优先，每一步都可查、可停、可回滚。

最后问一句：你们写回滚的时候，是只校验退出码，还是会去比对文件哈希？我这边发现光看退出码在跨机器上不太够用，想听听别人怎么处理的。