Terraform 1.16.5 修了两个崩溃：tainted 状态与删除时的空身份

hashicorp/terraform 发布 1.16.5，一个小版本但修的是两个会导致崩溃的问题。

修了什么 一是由 tainted 实例状态且没有有效 status 触发的崩溃。二是资源删除过程中的 nil-identity panic。

这两个都不是“功能不好用”，而是进程直接崩。在 CI 流水线里遇到就是任务中断，在手动操作时遇到更麻烦——terraform 进程异常退出可能留下不完整的 state 文件。

tainted 状态为什么会出这个问题 tainted 是 terraform 用来标记“创建成功但后续步骤失败”的资源。正常流程下它会有一个明确的 status，但在某些异常中断后，状态记录可能残缺。以前遇到这种情况 terraform 可能直接崩，现在能正确处理。

应该做的几件事

1. 尽快升到 1.16.5。崩溃类修复没有观望的理由。
2. 升级前备份 state 文件。虽然这是 patch 版本，但涉及 state 处理逻辑，备份是零成本保险。
3. 检查你的 CI 里有没有因为 terraform 异常退出而被标记为“环境故障”的历史任务，可能就是这两个 bug。
4. 如果历史上有因为这俩 bug 中断的操作，本地 state 和云端实际资源可能不一致，跑一次 plan 核对。

关于版本策略 Terraform 的 patch 版本一般很安全，但涉及 state 读写逻辑的例外。建议的做法是：patch 版本照升，但升级后先在一个非关键 workspace 上跑一遍完整的 plan 和 apply 流程，确认没问题再推广到生产环境。

顺带提醒 resource 删除时的 nil-identity 这类问题，在使用自定义 provider 时更容易触发。如果你的栈里有第三方 provider，升级后重点测一下 destroy 流程——创建流程测不出来这类问题。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

涉及 state 读写的补丁不能无脑升，先备份再在非关键 workspace 跑一遍完整 plan 和 apply。用第三方 provider 的重点测 destroy，创建流程测不出这类崩溃。

进程直接崩比报错难处理多了，尤其手动操作时 state 文件可能停在半截。我们的做法是 plan 之前先把 state 备份一份，配合远端存储加锁，能挡掉大部分麻烦。tainted 这条也提醒我，异常实例堆积久了容易触发边界情况，定期清理比留着攒一堆告警有用。

进程崩掉留下不完整状态文件最麻烦，恢复起来比重跑还费劲。我们的规矩是执行前强制备份状态，流水线里再加超时和锁检查。这次修的问题属于低概率高损失，升级优先级应该排在功能需求前面，别等真崩了才想起来。