真正安全的销毁需“可控范围+可中断验证+事后兜底”三步：先用terraform state list确认仅含测试资源，再用-target限定范围或-dry-run生成可审plan，最后处理残留资源并断开跨模块依赖。
直接用 terraform destroy 是最危险的起点——它不区分测试环境和生产配置，也不管你有没有手动改过资源状态。真正安全的销毁，核心在于「可控范围 + 可中断验证 + 事后兜底」三步缺一不可。
怎么避免误删非测试资源
Terraform 默认会读取当前工作目录的 state 文件，并据此决定销毁哪些资源。如果你在多个环境共用同一份代码但没隔离 state，terraform destroy 很可能把 staging 或 prod 的资源一起干掉。
- 确认当前
terraform state list输出只包含你预期的测试资源（比如都带-test-或loadtest-前缀） - 强制限定销毁范围：用
-target参数逐个指定，例如terraform destroy -target=aws_instance.fleet_test_server -target=aws_rds_cluster.loadtest_db - 如果用了 remote state（如 S3 + DynamoDB），检查 backend 配置是否指向了专用的测试 state 文件路径，而不是共享的根路径
为什么不能跳过 plan 阶段就执行 destroy
terraform destroy 本质是先做一次隐式 plan，再执行销毁。但这个过程默认不输出详细计划，容易漏看级联影响——比如删一个 ALB 可能顺带删掉关联的 Target Group 和 Listener，而这些未必是你想清掉的。
- 务必先运行
terraform destroy -dry-run -out=tfplan（Terraform v1.1+ 支持），生成可审查的 plan 文件 - 用
terraform show tfplan确认所有将被销毁的资源都在测试命名空间内，且没有意外的依赖项残留 - 特别注意
azurerm_resource_group或aws_vpc这类顶层资源：它们一旦被删，子资源全灭，但某些云厂商（如 Azure）对 Key Vault、Log Analytics Workspace 有prevent_destroy = true保护，plan 里会明确标出“will be skipped”
销毁失败后怎么手动收尾
网络超时、权限不足、资源被其他服务锁定（如 RDS 正在被备份任务占用），都可能导致 terraform destroy 卡在中间状态。此时 state 文件已部分更新，但云上资源残留，形成“半销毁”脏状态。
- 先查
terraform state list，对比云控制台，找出那些在 state 里标记为 “deleted” 但实际还活着的资源 - 对每个残留资源，用
terraform state rm <resource-address></resource-address>把它从 state 中移除，再手动在控制台或 CLI 删除 - 如果整个 state 已混乱，别硬修——备份当前
terraform.tfstate，然后用terraform import重新导入关键资源，再重试 destroy
最容易被忽略的是跨模块引用和远程状态依赖。比如 Fleet 压测环境里，signoz.tf 模块会通过 data "terraform_remote_state" 读取独立部署的 SigNoz 集群信息；销毁主环境时若没关掉这个 data source，Terraform 会尝试去拉取那个远程 state，一旦失败就阻塞销毁流程。这类隐式依赖必须在销毁前人工断开或注释掉。
