workspace本质是状态文件隔离而非资源隔离，仅切换terraform.tfstate文件，不改变资源配置、provider设置或云账号/区域，需配合terraform.workspace变量、count/for_each及独立backend路径实现安全多环境管理。
Workspace 本质是状态文件隔离，不是资源隔离
Terraform 的 workspace 只会切换当前工作区对应的状态文件（terraform.tfstate），不会自动修改资源配置、不改变 provider 配置、也不影响资源实际部署的云账号/区域。如果你用同一套代码在 dev 和 prod workspace 中 apply，但没做任何变量或条件区分，最终两个环境会尝试管理完全相同的资源（比如同名的 AWS S3 bucket），导致冲突或覆盖。
常见错误现象：Error: Error creating S3 bucket: BucketAlreadyExists 或 Resource already managed by another state —— 这说明你误以为 workspace 能“自动分环境”，其实它只管状态，不管逻辑。
- 必须配合
terraform.workspace变量或count/for_each控制资源生成逻辑 - 敏感配置（如
region、profile）仍需通过provider块显式区分，不能依赖 workspace - state 文件虽隔离，但 backend（如 S3 bucket + key）需提前规划好路径结构，否则多个 workspace 写入同一 key 会相互覆盖
怎么安全地初始化多 workspace 并绑定独立 state
关键在 backend 配置：用 workspace_key_prefix 或动态 key 把每个 workspace 映射到不同的 S3 对象路径。直接写死 key = "terraform.tfstate" 是大忌。
推荐做法（以 S3 backend 为例）：
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "env/${terraform.workspace}/terraform.tfstate"
region = "us-east-1"
}
}
- 首次运行前，先
terraform workspace new dev，再terraform init—— 此时会创建env/dev/terraform.tfstate - 切到 prod：
terraform workspace new prod→terraform init，自动使用env/prod/terraform.tfstate - 如果已有 legacy state，可用
terraform state mv -state-out=...手动迁移，但务必先备份原 state
如何用 terraform.workspace 区分资源配置
terraform.workspace 是字符串变量，可直接用于条件判断。但它不能替代模块输入或外部变量，仅适合轻量级差异（如命名后缀、实例类型微调）。
典型用法：
resource "aws_s3_bucket" "example" {
bucket = "myapp-${terraform.workspace}"
acl = "private"
}
resource "aws_instance" "web" {
count = terraform.workspace == "prod" ? 3 : 1
ami = var.ami_id
instance_type = terraform.workspace == "prod" ? "t3.large" : "t3.micro"
}
- 避免在复杂逻辑中嵌套多层
terraform.workspace == "xxx"，可改用lookup()查表或拆成不同module调用 -
terraform.workspace在module内不可见，子模块需通过input显式传入环境标识 - 别用它控制是否创建整个模块——该用
count = var.enable_module ? 1 : 0，而不是count = terraform.workspace == "prod" ? 1 : 0
为什么 production 环境不该依赖 workspace 切换
真实生产环境中，terraform workspace select prod 这种手动操作风险极高：容易切错、无法审计、难以集成 CI/CD。CI 流水线应明确指定 workspace（如 TF_WORKSPACE=prod），并限制 prod 只能由特定分支/PR 触发。
- 禁止在 prod workspace 中执行
terraform apply之前不加-plan或跳过 approval - 建议为每个环境建立独立的 Terraform 工作目录（即物理隔离），而非仅靠 workspace —— 尤其当 dev/prod 使用不同 provider 版本或 backend 配置时
- workspace list 里出现
default是隐患信号：说明有人可能忘了切环境就直接 apply，最好删掉 default 或重命名为legacy
真正难的不是建几个 workspace，而是确保每个 workspace 背后的配置、权限、审批流和可观测性都互不干扰 —— workspace 只是状态层面的第一道隔离，后面全得靠人来补全。
