本地terraform.tfstate在团队中不可用，因为每人执行apply都会生成或覆盖本地文件，导致状态不一致、资源重复创建或误删；必须使用带锁机制的远程后端（如S3+DynamoDB、Terraform Cloud）实现状态共享与并发控制。
为什么本地terraform.tfstate在团队里根本不能用
因为每个成员执行 terraform apply 时，都会生成或覆盖自己本地的 terraform.tfstate 文件。一旦小张刚创建完 VPC，小李在自己机器上跑了一次 terraform plan，他看到的“当前状态”其实是空的——Terraform 会认为所有资源都该被新建，而不是复用已存在的。结果就是重复创建、IP 冲突、甚至误删线上资源。
这不是概率问题，是必然发生。只要团队共用一套配置但没共享状态，冲突就只是时间问题。
必须用远程后端（remote backend），不是“建议”，是硬性要求
把 terraform.tfstate 存到远程后端，才能让所有人读写同一份真实状态。常用且生产可用的组合有：
- AWS 场景：S3 + DynamoDB（DynamoDB 用于加锁，防止并发写损坏状态）
- 通用场景：Terraform Cloud（免费版支持单用户，团队需付费）
- Kubernetes 原生环境：TF-Controller + Kubernetes Secret（状态存在
tfstate-${workspace}-${name}这样的 Secret 里）
配置示例（S3 后端）：
terraform {
backend "s3" {
bucket = "my-team-tfstate"
key = "prod/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "my-team-tfstate-lock"
encrypt = true
}
}
注意：bucket 和 dynamodb_table 必须提前手动创建好，且 IAM 权限要同时允许 S3 读写 + DynamoDB 读写+条件锁操作。
工作区（workspace）不是解决冲突的银弹，而是隔离维度
很多人以为开了 terraform workspace select prod 就能避免 dev 和 prod 冲突——其实它只隔离状态文件路径，不解决“多人同时改 prod”的问题。真正起作用的是后端的锁机制（比如 DynamoDB 的 LockID 字段）。
所以关键点是：
- 每个环境（dev/staging/prod）应使用独立的
key路径，比如dev/terraform.tfstate - 同一环境内，必须依赖后端锁（如 DynamoDB 表）来阻塞并发
apply -
terraform workspace只是帮你自动切换后端key，它本身不提供锁能力
状态损坏后最现实的恢复动作是什么
别指望从 Git 历史里找回 terraform.tfstate——那只是快照，不是权威状态。真正有效的恢复路径只有两条：
- 如果你用 TF-Controller：用
kubectl get secret tfstate-prod-myapp -ojsonpath='{.data.tfstate}' | base64 -d | gzip -d > terraform.tfstate拉取最新状态并本地校验 - 如果你用 S3 后端：启用 S3 版本控制（versioning），配合生命周期策略保留最近 7 天的版本；出问题时用
aws s3 cp s3://my-team-tfstate/prod/terraform.tfstate?versionId=xxx ./recovered.tfstate回滚
最容易被忽略的一点：远程后端本身也要做权限收敛。比如 S3 bucket 策略必须禁止 public read，DynamoDB 表不能开放 PutItem 给所有人——否则状态文件可能被恶意篡改，而 Terraform 不校验内容完整性。
