先跑一遍再按确认键：把 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 秒"从冲动变成核对。养成习惯之后你会发现：它挡住的永远不是"大事故"，而是那些你事后回想起来会觉得"当时就差看了一眼"的蠢事。