先跑一遍再按确认键：把 dry run 变成肌肉记忆

先说一个真实场景：一位做运维的朋友在某天早上 8 点执行了一条"清理过期日志"的脚本。脚本本身没写错，错的是他漏看了一个路径变量，`/data/tmp` 写成了 `/data`。二十分钟后整个数据目录清空。如果当时他先跑一遍 `--dry-run`，终端里会打印出将被删除的目录列表——一眼就能看出来不对。

一句话规则

**任何"撤销起来很贵"的操作，先以预览/演练的方式跑一遍，确认它真正会动到什么，再执行真的一版。**

dry run 不是测试，是一种"按确认键前的最后一道刹车"。

具体使用场景

**1. 批量改动文件和数据库。** 一次性重命名 500 个文件、批量更新 2000 条记录、迁移目录结构。正确动作：先跑 `--dry-run` 或 `explain`，把"将改动的对象清单"存成文件，人工抽查 10 条，数量对了再放行。

**2. 改配置。** nginx 反代、systemd 服务、crontab、SSH 配置、CI 流水线。正确动作：先验证（`nginx -t`、单元 dry-run、`cron` 试运行），并且先看一眼当前线上配置长什么样，再决定改动的最小范围。

**3. 第一次发布到真实环境。** 新域名上线、新格式全站启用、新模板推送给全体读者。正确动作：先发一个草稿链接自己走一遍完整流程——看页面、点链接、查响应头——确认无误再推给所有人。

**4. 让 AI 或脚本第一次碰真实资产。** 第一次让自动化工具删除文件、发邮件、改档期。正确动作：先让它输出"我打算做什么"，你确认清单，再开放执行权限。

什么情况不需要 dry run

- **三秒内可撤销的小改动**：改一个错别字、改一个文件名、撤回一条刚发的消息。为这种操作做演练只会拖慢节奏。

- **没有预览机制，也造不出预览**：某些一次性操作没有 dry-run 开关。这时候用"备份 + 小步执行"替代：先导出，先在 1 条记录上试，再分批放量。

- **你已经在执行回滚方案**本身：回滚流程就是在"反着干"，再做 dry run 是悖论，直接执行并盯住状态。

执行前检查清单

- [ ] 我能不能一句话说出这次操作"会改动什么"？（说不出 = 还没准备好）

- [ ] dry run 的输出已经**保存下来**，不是滚屏划过去的

- [ ] 抽查过 diff 的前几条、后几条、总数，而不是只扫了一眼

- [ ] 回滚方法此刻是可用的（命令还在终端里，备份还在盘上），不是"我记得怎么滚"

- [ ] 第一次 dry run 和预期不符 → 停下来改，改完**再跑一遍**，不靠猜

容易踩的坑

**坑一：dry run 和真实执行不是同一个环境。** 权限不同（预览时你有的权限，实际执行账号没有）、工作目录不同、时区不同、网络状态不同。同一个命令在预览里"改 3 个文件"，真实执行时可能"改 30 个"。对策：dry run 用和正式执行**相同的身份和目录**跑。

**坑二：把"dry run 通过"当成"一定会成功"。** 预览拿不到并发、时序、外部接口超时这些变量。dry run 只能保证"你想改的是你其实要改的"，不能保证执行过程不出意外。真正要漏一桶水的时候，通知机制要另做。

**坑三：滥用。** 每次改一个词都要求先预估、再演练、再批准，流程会把自己拖死。判断标准只有一条：**这次改动如果做错了，恢复它需要多少分钟？** 超过 10 分钟，值得演练；不超过，直接做并保存好撤销路径。

**坑四："扫了一眼输出"不算核验。** 人眼对长列表的扫描是不可靠的，尤其数字和单位（3 个文件 vs 3000 个文件）。把输出落到文件里，用 `wc -l` 数总数，用 `head`/`tail` 各看几条，才算看过了。

收尾

dry run 的价值不在技术，在于把"确认键前的最后 10 秒"从冲动变成核对。养成习惯之后你会发现：它挡住的永远不是"大事故"，而是那些你事后回想起来会觉得"当时就差看了一眼"的蠢事。