Terraform执行失败怎么安全回滚
当 Terraform 在 apply 过程中报错时，我怎么确认哪些资源已经创建成功、哪些资源还没生效，避免误判当前环境状态？
检查状态文件与云端资源差异
可以先查看 Terraform state 中记录的资源，再对照云平台实际资源是否一致。如果 apply 过程中断，部分资源可能已经创建成功，但 state 未及时更新。建议结合 terraform plan 重新生成变更预览，识别出状态文件与真实环境之间的差异，同时检查失败日志定位具体卡点。对于关键资源，还可以通过云平台控制台或 API 核对实例、网络、存储等对象是否已存在，从而判断环境是否进入部分生效状态。
我担心直接回退会影响那些已经正常创建或修改的资源，有没有更稳妥的处理方式来保留可用部分？
基于变更范围做精确回退
不要盲目执行大范围销毁操作，而是先确认失败点和已成功资源的边界。对于已经完成且业务可用的资源，优先保持现状；对出问题的资源单独处理，比如修正配置后重新 apply，或仅对特定资源执行针对性回滚。若使用模块化管理，也可以按模块拆分排查，减少误伤面。通过这种方式，可以把回滚范围控制在必要的最小集合内。
如果这次变更引入了错误，我应该怎么借助代码版本来恢复到之前验证过的可用配置？
切换到稳定版本并重新部署
可以将 Terraform 配置纳入 Git 等版本管理工具中，定位到最近一次稳定提交，将代码回退到该版本后再执行部署流程。这样做的好处是回滚逻辑清晰，便于审计和协作。回退前要确认依赖变量、状态文件和远端资源没有发生额外手工修改，必要时先做状态检查和备份。恢复到稳定版本后，再通过 plan 观察差异，确认只会生成预期的回滚变更。
如果执行中断导致状态文件异常，我该怎么保护现有环境，避免后续操作越修越乱？
先备份状态，再做修复或重建
在处理异常之前，应该先备份当前 state 文件，确保有可恢复的基线。若使用远端状态存储，也要确认锁机制是否已释放，避免并发修改造成二次损坏。接着根据情况判断是通过导入资源、修复 state，还是基于稳定版本重新同步状态。只要保留了状态快照，即使修复过程中出现偏差，也能回到原始现场继续分析。