为每个Azure DevOps流水线按Git特性分支创建并删除tfstate文件存在哪些问题？

虽然这种方式确实能规避tfstate锁定问题，但会带来一系列更棘手的问题：

• 孤儿资源与成本浪费：Terraform完全依赖tfstate来追踪云资源的状态，直接删除tfstate后，对应的云资源并不会被自动销毁。这些“无主”资源会一直留在云上持续产生成本，后续还得手动排查清理，尤其当分支数量多的时候，工作量会非常大。

• 状态一致性冲突：当特性分支合并到主分支时，主分支的tfstate并没有记录特性分支创建的资源。如果合并后的Terraform代码包含这些资源定义，执行主分支流水线时会重复创建；如果代码没同步，这些资源就会变成游离状态，和主分支管理的资源环境脱节，导致整体配置混乱。

• 完全丢失操作追溯能力：tfstate不仅是状态记录，还包含资源的变更历史。删除tfstate后，这个分支上所有的资源操作痕迹都会消失，后续排查问题（比如某个异常资源的来源、变更时间）时完全没有依据，协作过程中也没法回溯开发过程。

• 流水线冗余开销：每个分支都要重新初始化Terraform环境、创建新的tfstate、拉取提供者依赖，这些重复操作会显著增加流水线的执行时间和资源消耗，当团队并行开发的分支较多时，这个开销会被放大。

• 误操作后的恢复成本极高：如果不小心删除了还在开发中的分支tfstate，或者分支合并前提前删除了tfstate，你要么手动去云平台销毁资源，要么得把现有资源重新导入到新的tfstate中——导入过程需要精准匹配资源ID和配置，很容易出错，而且非常耗时。

内容的提问来源于stack exchange，提问作者Pshymonz