声明式基础设施描述期望结果，再由工具计算变更。命令式脚本同样可以查询已有资源、实现幂等性；重复创建不是脚本天生无法避免的命运。Terraform 的价值，在于把配置、资源身份、依赖关系和拟执行操作放进一个共同模型，让评审者能够一起检查。

因此，值得评审的不只是配置文件的 diff。一次看起来无害的重命名可能改变资源地址，而完全没改过的配置也可能因为有人操作了运行中的系统而产生计划。需要同时读懂「想做什么」以及「工具现在具体提议做什么」。文件可追踪，并不自动等于所有操作都安全。

计划是提案，不是事务保证

普通 plan 通过 provider 读取受管理对象，把刷新后的观察结果与配置比较，再提出创建、更新、替换或删除操作。未知值、provider 的实现、执行权限，以及计划到执行之间发生的变化，都使它无法保证成功，也不能把输出理解成未来所有 API 调用的完整逐条清单。

保存计划可以让 apply 使用被评审的那份提案，而不是自动重算另一份，但并不会冻结远端系统。状态发生变化可能使保存的计划失效，执行也可能在完成部分操作后报错。计划文件和状态可能包含敏感信息，应作为受控产物保存，不要为了排错就把完整内容贴到公开日志里。

成功 apply 之后，如果输入、配置和外部环境稳定，通常应当不再出现新的变更。若持续有差异，就要检查外部控制器、计算属性、provider 缺陷和不断变化的输入。一个干净的计划只说明此次受管理范围内没有拟执行差异，不能证明云账户里所有资源都已被纳入清单，也不能保证业务服务健康。

状态保存的是身份关系

状态把配置地址绑定到真实对象，并保存 Terraform 需要的其他信息。丢失映射不会立刻删除远端资源；之后的计划可能提议创建新对象，而 apply 究竟会建出重复资源，还是遇到名称冲突，取决于 provider 和服务本身。不能把某一次 already exists 错误推广成所有资源的必然结果。

恢复时应先检查后端历史版本与可用快照。当恢复快照不适合或不可行时，import 可以把受支持的既有对象重新关联到配置地址。除了命令行方式，也有配置驱动的导入流程，并不一定要逐个手工敲命令。导入之后仍需核对资源配置和执行计划，身份绑定完成不意味着下一次 apply 一定没有变化。

共享状态需要访问控制、可恢复的历史，以及具备合适锁定能力的后端。并非所有后端都支持锁；获取锁失败会使操作停止，是否等待、等待多久还取决于锁超时等命令选项。不要为了绕过另一个合法运行而禁用锁，也不要把状态版本历史等同于完整基础设施审计。后端保存了什么记录、能恢复到哪里，都需要独立确认。

漂移与重构是两种决定

已经被状态追踪的资源在外部被修改后，需要决定保留新值还是恢复配置值。保留通常意味着更新配置，普通属性漂移不需要重新 import。refresh-only apply 会更新 Terraform 的记录，而不按照配置去改远端对象；它不会替你编辑配置，因此下一次普通计划仍可能提议把外部改动撤回。

被忽略的属性和 provider 的资源模式，也会影响哪些差异产生操作。控制台变更可能有自己的审计日志，真正的团队问题往往不是「绝无记录」，而是事故处置记录没有关联到下一次部署。把最终要保留的值写清楚，比单纯让一次 refresh 看起来成功更重要。

如果只改地址，却没有记录新旧地址的关系，就可能得到删除旧对象、创建新对象的提案。moved 块可以显式说明这种关系，也包括受支持的模块内迁移，所以兼容的重构不必重建资源。不过，伴随发生的其他配置变化仍可能要求替换对象。直接删掉资源块通常会提议销毁，除非明确使用了合适的移除管理流程。

坏掉的样子

事故中有人临时调大实例规格，却没同步配置；下一次无关的 apply 随后提议缩小它。应当评审相关操作，并记录长期希望保留的值。计划退出码二表示有非空差异，不专门表示漂移，也不自动代表危险或失败。把所有二都当成故障，容易制造让人忽略的告警噪声。

面对意外的 destroy，先比较旧地址和新地址，再决定是否批准。面对「资源不见了」，先确认选中的后端和 workspace，而不是立即断言状态丢失。恢复期间要停止并发写入；一份看起来合理的空状态，并不构成重新创建全部资产的依据。把账单、对象标识和配置地址对应起来，才有恢复的基础。

快速验证

安装 Terraform 1.4 或更新版本后，在下面新建的一次性目录中执行。内置的 terraform_data 资源不需要外部 provider、凭据或基础设施。这些 apply 命令只写入本实验的本地状态，不要把示例混入已有的生产配置目录：

lab=$(mktemp -d)
cd "$lab" || exit 1
cat > main.tf <<'HCL'
resource "terraform_data" "old" { input = "kept" }
HCL
terraform init -input=false
terraform validate
terraform apply -input=false -auto-approve
terraform state show terraform_data.old
cat > main.tf <<'HCL'
resource "terraform_data" "new" { input = "kept" }
HCL
terraform plan
cat >> main.tf <<'HCL'
moved {
  from = terraform_data.old
  to   = terraform_data.new
}
HCL
terraform validate
terraform plan -out=moved.tfplan
terraform apply -input=false moved.tfplan
terraform state show terraform_data.new
terraform plan -detailed-exitcode

在 Terraform 1.13.3 上实际运行后，没有记录关系的重命名会提议创建一个、删除一个；不要执行这个中间计划。加上 moved 后，计划中的新增、修改、删除数量均为零，迁移前后展示的对象标识保持相同，最后一次计划退出码为零。只有地址迁移的保存计划仍可能返回详细退出码二，因为状态中的地址确实发生了变化。

这验证了真实 Terraform 客户端的本地计划和地址迁移，没有验证云 provider 导入、远端漂移检测或后端锁。详细退出码的一般含义是：零表示没有变更，一表示错误，二表示存在变更。应该继续读具体动作，不能因为出现二就认定失败，也不能因为资源操作数为零就忽略状态映射的变动。

实验结束后，先用 cd - 返回原来的目录，再删除 $lab 指向的那一个临时目录。其中只保留本实验生成的配置、计划和本地状态；在明确清理前，这些文件仍会留在磁盘上。

来源