先跑一遍再按確認鍵：把 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 秒」從衝動變成核對。養成習慣之後你會發現：它擋住的永遠不是「大災難」，而是那些你事後回想起來會覺得「當時就差看了一眼」的蠢事。