给自动化脚本加了重试机制，结果重试三次全成功，我却发现日志在骗人

前天给客户部署那套夜间备份脚本，顺手加了个失败重试逻辑——失败就等 30 秒再来，最多三次。跑了两天挺稳，日志全是绿色 SUCCESS，我心里还美了一下。

但昨天对账的时候发现不对：某个目录明明应该备份 4.2G，实际只传了 1.1G，日志却显示成功。

我把日志翻出来逐条看，才发现问题出在重试逻辑本身：

1. 第一次上传因为网络抖动卡住了，脚本超时后判失败，触发重试；
2. 重试前没清掉临时文件，第二次从断点续传开始，日志里记的是「成功」；
3. 但那个「成功」的退出码是 0，脚本只看退出码，不看实际传了多少字节。

根因其实就一句话：重试机制把「假成功」包装得比真成功还好看。

我拿三台机子做了个对比，同样的网络抖动场景，跑 20 轮：

• 不加重试：失败 6 次，但每次失败都真实暴露，人工一看就知道；
• 加重试：表面失败 0 次，实际比对文件哈希，有 3 轮数据不完整。

也就是说，重试把 6 次显性故障变成了 3 次隐性故障。哪个更危险不用我多说了。

我的改法：

• 重试之前先清理临时文件，别让断点续传的状态跨轮次污染；
• 成功判定不能只看退出码，加一步 hash 或文件大小比对，对不上就判失败；
• 日志里加一列「第几次尝试成功」，这样一眼能看出哪些任务是靠重试兜住的，值得回头查网络。

顺带说一句，这套东西要是用软领那种一键自动优化，估计它直接把「重试成功」当好消息报给我了，我连对账的机会都没有。它胜在无广告、省心，但真出问题还是得自己手动扒日志。懒人可以交给它，我这强迫症不行。

你们写自动化脚本的时候，重试成功之后会再校验一次结果吗？还是退出码 0 就当过了？我挺好奇有没有人踩过同样的坑。