功能测试流程与自动化脚本
8.10 检查点与回退
Tip
真正的勇士，从不回头看爆炸。但聪明的工程师，永远会留一条回头的路。
1. 为什么要学这个?
周五下午 5 点，你上线了一个新功能。 5 点 10 分，老板冲进来说：“所有用户都登不上了！赶紧撤回！” 此时你的大脑一片空白：删哪行代码？怎么重新打包？数据库怎么办？
如果你没有提前设置好“检查点” (Checkpoints)，这一刻就是你的噩梦。 学会本章，你将拥有时光机：无论发生什么灾难，你都能在 30 秒内让世界回到和平的样子。
2. 核心概念：Checkpoints (时光机存档)
1. Git Tag (代码的里程碑)
每一个 Commit 只是游戏里的自动存档。
而 Tag 是你在打 Boss 前手动存的那个关键存档。
v1.0.0: 这是一个稳定的版本。v1.0.1: 这是一个修复了 Bug 的版本。
2. Git Revert (安全的后悔药)
很多人出事了喜欢用 git reset (重置时间线)。这对多人协作是毁灭性的。
Git Revert 是生成一个新的提交，用来抵消上一次的错误。历史记录还在，但错误被修正了。
3. 解决方案 (HOW)
场景一：发版前的仪式 (打 Tag)
不要在那瞎提交。每次上线前，必须以此为誓：
# 1. 确认测试通过
npm run test
# 2. 打上标签 (就像给时间打个结)
git tag v2.0.0
# 3. 推送到云端
git push origin v2.0.0
场景二：出事后的急救 (Vercel 回滚)
如果你是用 Vercel 托管，甚至不需要敲代码。
- 打开 Vercel Dashboard -> Deployments。
- 找到上一个绿色 (Ready) 的部署记录。
- 点击 "Instant Rollback" (瞬间回滚)。
- 30 秒内，你的网站流量就会被切回旧版本。
场景三：代码层面的撤销 (Git Revert)
# 1. 找到那个闯祸的 Commit ID (比如 a1b2c3d)
git log
# 2.不仅不删它，反而生成一个反向补丁
git revert a1b2c3d
# 3. 推送这个“修正”
git push
4. 真实案例
Story
GitLab 的 300GB 删库惨案 (2017)
2017 年，一位 GitLab 工程师意外执行了 rm -rf，删除了 300GB 的生产数据库。
最绝望的时刻：
他们试图恢复备份，却发现：
- 数据库快照 (Snapshots) 是空的。
- 磁盘镜像 (Disk Images) 不可读。
- 常规备份脚本早在几个月前就报错了，但没人看。
Vibe 心法：
- 没有被还原测试过的备份，等于没有备份。
- 回滚能力 (Rollback Capability) 是比新功能更重要的功能。上线前先问自己：如果这就炸了，我怎么在 1 分钟内救回来？
5. 本章小结
- 打 Tag：这是给你的代码买的保险。
- 用 Revert：永远向前修正，不要抹除历史。
- 常演练：如果你从来没试过从备份中恢复，那你其实是在裸奔。