在 apply 之前评审 Terraform Plan

把 plan 作为可评审的产物保存，要求人工批准，并且只 apply 已批准的那份 plan，确保进入云端的正是评审过的变更。

概述

Terraform 的 Pull Request 展示的是代码改动，而不是实际影响。真正的影响是 plan，必须被评审和批准的也是 plan。常见的两种错误流程是：在 PR 中生成 plan，却在 apply 时重新 plan；或者合并后直接用 -auto-approve 应用。前者可能应用与评审不一致的内容，后者等于没有评审。正确做法是只 plan 一次，保存 plan 文件，批准该产物，然后 apply 同一个文件。

步骤

生成保存的 plan，并输出可读文本供评审：

terraform plan -input=false -lock-timeout=5m -out=tfplan
terraform show -no-color tfplan > plan.txt

单独提取删除与替换动作，避免被大量标签更新淹没：

terraform show -json tfplan \
  | jq -r '.resource_changes[] | select(.change.actions | index("delete")) | .address'

批准后只应用保存的 plan，不要重新 plan：

terraform apply -input=false tfplan

记录 plan 摘要，与部署记录一并保存：

sha256sum tfplan

验证

plan.txt 应包含新增、修改、销毁的数量与明细，并作为构建产物附在运行记录上；删除列表必须逐条确认，尤其是数据库等有状态资源。apply 日志中的摘要应与评审时记录的 sha256 一致。若 apply 报 plan 已过期，说明 plan 之后 state 发生变化，应回到同一 workspace 重新 plan 并重新评审，而不是强行使用旧文件。

注意事项

plan 无法预测 plan 与 apply 之间在云厂商侧发生的漂移。
plan 文件包含敏感值，应限制访问权限并缩短保留时间。
不要在 apply 阶段再次执行 plan，否则批准的内容可能被替换。
有意的替换必须在 PR 中说明，并附上迁移或备份步骤。
apply 之后仍应在同一流水线中执行一次 refresh，确认实际状态。