Terraform变量依赖与条件逻辑：构建可演进的基础设施程序

1. 项目概述：用变量、依赖与条件逻辑让Terraform真正“活”起来

你有没有写过这样的Terraform代码：一个模块硬编码了5个AWS区域、3种实例类型、2套安全组规则，改一次环境就得全局搜索替换；或者一模一样的VPC配置，在开发环境要开NAT网关，在预发环境要关，在生产环境又要加一个额外的路由表——结果你复制粘贴出三份几乎一样的.tf文件，每次修bug都要同步改三处？这根本不是基础设施即代码（IaC），这是“基础设施即复制粘贴”。我干了八年云平台工程，从最早手写CloudFormation模板，到后来用Ansible套壳Terraform，再到今天带团队统一落地Terraform企业级实践，最深的体会就是：Terraform的生命力不在于它能创建多少资源，而在于它能否像真实编程语言一样思考、判断和复用。标题里提到的Variables（变量）、Dependencies（依赖）、Conditionals（条件逻辑）——这三者不是语法糖，而是把Terraform从“配置生成器”升级为“基础设施编译器”的核心引擎。Variables让你把变化点抽离成可注入的参数；Dependencies确保资源按真实世界因果关系顺序创建（比如先有VPC，才有子网，才有EC2）；Conditionals则赋予它if/else能力，让同一份代码在不同环境、不同业务场景下自动切换行为。这不是炫技，是每天都在发生的刚需：CI/CD流水线里自动识别TF_ENV=prod并启用加密密钥轮转；多租户SaaS平台中根据客户等级动态开启/关闭WAF防护层；甚至一个GitOps仓库里，通过分支名feature/redis-cache自动注入Redis模块并关联到对应应用服务。接下来我会带你一层层拆解，怎么用这三把刀，把僵硬的.tf文件变成可演进、可测试、可审计的基础设施程序。

2. 核心设计思路：为什么必须用变量+依赖+条件，而不是硬编码？

2.1 变量不是“填空题”，而是定义基础设施的“契约接口”

很多人把Terraform变量当成简单的占位符——比如variable "region" { default = "us-east-1" }，然后在aws_instance里直接引用${var.region}。这没错，但远远不够。真正的变量设计，本质是在定义模块与外部世界的契约接口。举个真实案例：我们给金融客户做多云灾备系统时，最初所有云厂商配置都混在一个模块里，变量列表长得像电话黄页。后来重构，我们把变量分成三层：

• 环境层变量（env.tfvars）：env_name = "prod"、region_primary = "cn-north-1"、region_backup = "cn-south-1"
• 能力层变量（features.tf）：enable_encryption = true、enable_audit_logging = false、backup_retention_days = 30
• 策略层变量（policies.tf）：iam_role_policy_arns = ["arn:aws:iam::123456789012:policy/ReadOnlyAccess"]

这样分层后，开发环境只需传入env_name="dev"和enable_encryption=false，生产环境则强制校验enable_audit_logging=true。关键点在于：变量声明本身就要携带业务语义和约束。比如enable_audit_logging不能只是bool，而要加上描述：“金融合规要求，生产环境必须开启，否则terraform plan会报错”。我们用validation块实现：

variable "enable_audit_logging" { description = "是否启用审计日志（金融等保三级强制要求）" type = bool default = false validation { condition = var.env_name != "prod" || var.enable_audit_logging == true error_message = "生产环境（env_name=prod）必须启用审计日志（enable_audit_logging=true）" } }

这个设计让Terraform从“执行器”变成了“合规检查器”。变量不再是被动接收值，而是主动参与决策——这才是IaC该有的样子。

2.2 依赖不是“谁先谁后”，而是表达资源间的因果链

新手常犯的错误是：看到depends_on就以为解决了依赖问题。比如写depends_on = [aws_vpc.main]让子网等VPC创建完再建。这确实能避免“VPC not found”错误，但掩盖了更深层的问题：Terraform的隐式依赖比显式depends_on更强大，也更危险。真实世界里，EC2实例依赖子网，是因为子网ID要作为参数传给aws_instance；子网依赖VPC，是因为VPC ID要作为参数传给aws_subnet。这种参数传递形成的数据流依赖，才是Terraform真正理解的依赖关系。depends_on只是兜底方案，用于处理无法通过参数传递表达的弱耦合（比如某个Lambda函数需要在RDS集群完全启动后才触发初始化）。

我们曾踩过一个经典坑：在EKS集群中，aws_eks_cluster资源创建后，需要等待cluster_endpoint可用才能创建aws_eks_node_group。如果只用depends_on，Terraform会认为只要aws_eks_cluster资源状态变为created就结束，但实际上API端点可能还在冷启动。正确做法是利用隐式依赖+null_resource+local-exec健康检查：

resource "null_resource" "wait_for_eks_endpoint" { triggers = { cluster_endpoint = aws_eks_cluster.main.endpoint } provisioner "local-exec" { command = <<-EOT until curl -k -f https://${aws_eks_cluster.main.endpoint}/healthz > /dev/null 2>&1; do echo "Waiting for EKS endpoint ${aws_eks_cluster.main.endpoint}..." sleep 10 done echo "EKS endpoint is ready!" EOT } } resource "aws_eks_node_group" "main" { # ... 其他配置 depends_on = [null_resource.wait_for_eks_endpoint] }

这里triggers绑定了aws_eks_cluster.main.endpoint，强制null_resource在endpoint变化时重新执行；depends_on则确保node group在健康检查通过后才创建。依赖的本质是控制执行时序，而时序的依据必须是可验证的状态信号，不是资源创建完成的模糊概念。

2.3 条件逻辑不是“if-else开关”，而是基础设施的“策略引擎”

把count = var.env_name == "prod" ? 1 : 0当成条件逻辑，就像把汽车油门当成了开关——能动，但不会驾驶。真正的条件逻辑，要能组合、嵌套、推导。比如我们为电商大促设计的弹性架构：

• 基础层：始终部署1台主数据库（count = 1）
• 弹性层：当is_promotion = true且promotion_type = "flash_sale"时，额外部署2台只读副本（count = 2）
• 安全层：当is_promotion = true时，自动启用数据库审计日志并设置保留期为90天（retention_period = 90），否则为7天

这需要三层条件嵌套：

# 只读副本数量 locals { read_replica_count = ( var.is_promotion == true && var.promotion_type == "flash_sale" ? 2 : var.is_promotion == true && var.promotion_type == "pre_order" ? 1 : 0 ) } # 审计日志保留期 locals { audit_retention_days = var.is_promotion == true ? 90 : 7 } # 部署只读副本 resource "aws_db_instance" "read_replica" { count = local.read_replica_count # ... 配置 backup_retention_period = local.audit_retention_days }

更进一步，我们把条件逻辑封装成策略函数。在modules/networking/vpc/main.tf里定义：

locals { # 根据环境和合规等级推导VPC CIDR vpc_cidr = ( var.env_name == "prod" && var.compliance_level == "pci_dss" ? "10.100.0.0/16" : var.env_name == "prod" ? "10.200.0.0/16" : "10.10.0.0/16" ) # 根据VPC CIDR自动计算子网CIDR（避免手动计算出错） public_subnets = [ cidrsubnet(local.vpc_cidr, 8, 0), cidrsubnet(local.vpc_cidr, 8, 1) ] private_subnets = [ cidrsubnet(local.vpc_cidr, 8, 2), cidrsubnet(local.vpc_cidr, 8, 3) ] }

这里cidrsubnet函数把条件判断和网络计算结合，让Terraform具备了“推理”能力。条件逻辑的终极目标，是让人类工程师从重复计算和记忆规则中解放出来，把确定性工作交给机器。

3. 实操细节拆解：变量、依赖、条件的黄金组合拳

3.1 变量声明的工业级规范：从命名到验证的完整链条

变量是Terraform的入口，入口不规范，后面全是坑。我们团队执行的变量声明五步法：

第一步：命名即文档
不用vpc_cidr，而用primary_vpc_cidr_block；不用instance_type，而用application_server_instance_type。前缀明确作用域（primary_表示主VPC），后缀说明类型（_cidr_block），中间用下划线分隔语义单元。这样在IDE里输入primary_就能自动补全所有主环境变量。

第二步：类型强制收敛
禁止使用type = any。哪怕要传复杂对象，也定义明确结构：

variable "database_config" { description = "数据库配置参数" type = object({ engine = string engine_version = string instance_class = string storage_gb = number multi_az = bool }) default = { engine = "mysql" engine_version = "8.0.32" instance_class = "db.t3.medium" storage_gb = 100 multi_az = false } }

这样做的好处是：terraform validate能提前发现storage_gb = "100"这种类型错误；IDE能提供精准字段提示；更重要的是，当其他模块要复用这个变量时，结构一目了然。

第三步：默认值即基线
默认值不是随便填的，而是代表“最小可行生产环境”。比如enable_monitoring = true、encryption_at_rest = true。新团队成员拉取代码后，terraform apply出来的就是符合安全基线的环境，而不是一个裸奔的测试实例。

第四步：验证即守门员
除了前面提到的validation块，还要用assert函数做运行时断言（Terraform 1.3+）：

locals { assert_valid_region = assert( contains(["us-east-1", "us-west-2", "eu-west-1"], var.region), "region must be one of: us-east-1, us-west-2, eu-west-1" ) }

这个断言在terraform plan阶段就执行，比等到apply失败再排查快得多。

第五步：敏感信息零明文
所有密码、密钥、token必须标记sensitive = true，并在CI/CD中通过环境变量注入：

variable "db_password" { description = "数据库主用户密码" type = string sensitive = true # 不设default，强制从环境变量或tfvars注入 }

在CI/CD脚本中：

export TF_VAR_db_password=$(aws secretsmanager get-secret-value --secret-id prod/db/password --query 'SecretString' --output text) terraform apply -auto-approve

这样既保证本地开发可用terraform.tfvars，又确保生产环境密钥永不落盘。

提示：变量文件加载顺序是terraform.tfvars→*.auto.tfvars→-var-file=指定的文件。我们约定terraform.tfvars放通用配置（如region），prod.auto.tfvars放生产专属配置（如db_password），并通过Git忽略*.auto.tfvars防止误提交。

3.2 依赖管理的实战心法：何时用隐式依赖，何时用显式depends_on

依赖管理的核心原则：优先用隐式依赖，仅在必要时用显式depends_on。隐式依赖是Terraform的“本能”，显式依赖是“人工干预”。

隐式依赖的三大黄金场景：

1. 参数传递依赖：资源A的输出属性被资源B作为输入参数使用。这是最自然、最可靠的依赖。例如：

   resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" } resource "aws_subnet" "public" { vpc_id = aws_vpc.main.id # 明确依赖aws_vpc.main cidr_block = "10.0.1.0/24" }

   这里aws_subnet.public的vpc_id参数直接引用aws_vpc.main.id，Terraform自动构建依赖图。

2. 元数据依赖：用for_each或count遍历资源时，遍历源本身构成依赖。例如：

   resource "aws_security_group" "app" { for_each = toset(["web", "api", "worker"]) name = "sg-${each.value}-${var.env_name}" vpc_id = aws_vpc.main.id } resource "aws_security_group_rule" "ingress" { for_each = toset(["web", "api", "worker"]) type = "ingress" from_port = 80 to_port = 80 protocol = "tcp" security_group_id = aws_security_group.app[each.value].id # 依赖sg资源 source_security_group_id = aws_security_group.app["web"].id }

   aws_security_group_rule.ingress的for_each遍历toset，但它的security_group_id又引用了aws_security_group.app的输出，形成双重依赖。

3. 数据源依赖：data块的查询结果被用作资源参数。例如：

   data "aws_ami" "ubuntu" { most_recent = true filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"] } owners = ["099720109477"] } resource "aws_instance" "web" { ami = data.aws_ami.ubuntu.id # 依赖data块 instance_type = "t3.micro" }

显式depends_on的四大慎用场景（必须满足以下任一条件才用）：

• 弱耦合时序控制：两个资源无参数关联，但业务上必须A先于B。比如先创建S3桶，再用aws_s3_bucket_object上传初始化脚本。
• 规避API最终一致性延迟：某些云服务API返回“创建成功”后，资源实际未就绪（如AWS CloudFront分发）。此时用null_resource+local-exec做健康检查，再用depends_on绑定。
• 跨模块资源引用：模块A输出一个ID，模块B想用但不通过参数传递（不推荐，应优先重构为参数传递）。
• 规避Terraform已知Bug：极少数情况下，Terraform解析器未能正确识别隐式依赖（查阅官方GitHub Issues确认）。

注意：depends_on不能解决所有问题。我们曾遇到AWS EBS卷快照创建后，aws_ebs_snapshot_copy资源因权限问题失败。depends_on只能保证顺序，不能保证状态。最终解决方案是：在aws_ebs_snapshot_copy中用lifecycle块重试，并配合time_sleep资源等待足够时间。

3.3 条件逻辑的高阶玩法：从简单count到动态模块组装

条件逻辑的威力，在于它能把静态配置变成动态程序。我们按复杂度分三级实践：

第一级：基础条件（count & for_each）
这是入门必会，但要注意陷阱：

• count = 0会删除资源，count = 1会创建。如果想“禁用但保留”，要用lifecycle.ignore_changes。
• for_each的键必须是唯一字符串。常见错误是用uuid()函数生成键，导致每次plan都变，引发不必要的销毁重建。正确做法是用有意义的标识符：

  # 错误：每次plan都生成新uuid # for_each = { for i in range(3) : uuid() => i } # 正确：用稳定标识符 for_each = toset(["web", "api", "worker"])

第二级：条件推导（locals + ternary）
用locals块封装复杂条件，让主资源块干净：

locals { # 根据环境和规模推导实例类型 instance_type = ( var.env_name == "prod" && var.workload_size == "large" ? "m5.2xlarge" : var.env_name == "prod" ? "m5.xlarge" : "t3.micro" ) # 根据合规等级推导安全组规则 security_group_rules = [ for rule in var.security_rules : { port = rule.port protocol = rule.protocol cidr_blocks = rule.env == "prod" ? ["0.0.0.0/0"] : ["10.0.0.0/8"] } ] }

第三级：动态模块组装（module + for_each + dynamic blocks）
这才是Terraform的“王炸”。我们为AI平台构建的模型服务架构，用一个main.tf动态组装整套基础设施：

# 根据模型类型动态选择模块 module "model_service" { for_each = { "llm" = { module_path = "./modules/llm-serving" replicas = var.llm_replicas gpu_count = 2 } "cv" = { module_path = "./modules/cv-serving" replicas = var.cv_replicas gpu_count = 1 } } source = each.value.module_path model_name = each.key replicas = each.value.replicas gpu_count = each.value.gpu_count vpc_id = aws_vpc.main.id subnet_ids = aws_subnet.private[*].id }

更绝的是，模块内部用dynamic块生成可变数量的安全组规则：

# 在./modules/llm-serving/main.tf中 resource "aws_security_group" "main" { name = "sg-${var.model_name}-${var.env_name}" description = "Security group for ${var.model_name} service" vpc_id = var.vpc_id dynamic "ingress" { for_each = var.ingress_ports content { from_port = ingress.value.from_port to_port = ingress.value.to_port protocol = ingress.value.protocol cidr_blocks = ingress.value.cidr_blocks } } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } }

这样，只需修改顶层变量var.ingress_ports = [{from_port=8080, to_port=8080, protocol="tcp", cidr_blocks=["10.0.0.0/8"]}]，就能动态生成任意数量的入站规则。条件逻辑的终点，是让Terraform代码像乐高一样，用少量基础模块拼出无限可能的基础设施形态。

4. 完整实操流程：从零搭建一个支持多环境的Web应用栈

4.1 项目结构设计：按职责分层，拒绝大杂烩

我们采用业界公认的Terraform企业级目录结构，根目录下分四层：

terraform-webapp/ ├── environments/ # 环境层：prod/, staging/, dev/ │ ├── prod/ │ │ ├── main.tf # 调用modules，注入环境变量 │ │ └── terraform.tfvars # 生产专属配置（密钥、容量等） │ └── dev/ │ ├── main.tf │ └── terraform.tfvars ├── modules/ # 模块层：networking/, compute/, database/ │ ├── networking/ │ │ ├── main.tf # VPC、子网、路由表 │ │ ├── variables.tf # 模块输入变量 │ │ └── outputs.tf # 模块输出 │ └── compute/ │ ├── main.tf # EC2、ASG、ALB │ └── variables.tf ├── global/ # 全局层：providers.tf, versions.tf └── README.md

这种结构让变更影响范围一目了然：改modules/networking/只影响网络，改environments/prod/只影响生产环境。我们禁止在environments/下直接写资源，所有资源必须通过module调用。

4.2 编写核心模块：Networking模块的变量与条件实战

以modules/networking/vpc/main.tf为例，展示如何融合变量、依赖、条件：

# modules/networking/vpc/variables.tf variable "env_name" { description = "环境名称（dev/staging/prod）" type = string } variable "region" { description = "AWS区域" type = string default = "us-east-1" } variable "cidr_block" { description = "VPC CIDR块" type = string default = "10.0.0.0/16" } variable "enable_nat_gateway" { description = "是否启用NAT网关（dev/staging通常不需要）" type = bool default = false } variable "az_count" { description = "可用区数量（prod建议3，dev建议1）" type = number default = 2 } # modules/networking/vpc/main.tf # 1. 创建VPC（基础资源，无条件） resource "aws_vpc" "main" { cidr_block = var.cidr_block enable_dns_hostnames = true enable_dns_support = true tags = { Name = "vpc-${var.env_name}" Environment = var.env_name } } # 2. 动态创建子网：根据az_count生成多个子网 resource "aws_subnet" "public" { count = var.az_count vpc_id = aws_vpc.main.id cidr_block = cidrsubnet(var.cidr_block, 8, count.index) map_public_ip_on_launch = true availability_zone = data.aws_availability_zones.available.names[count.index] tags = { Name = "public-subnet-${count.index + 1}-${var.env_name}" Environment = var.env_name } } # 3. 条件创建NAT网关（仅当enable_nat_gateway为true时） resource "aws_eip" "nat" { count = var.enable_nat_gateway ? 1 : 0 vpc = true tags = { Name = "eip-nat-${var.env_name}" Environment = var.env_name } } resource "aws_nat_gateway" "main" { count = var.enable_nat_gateway ? 1 : 0 allocation_id = aws_eip.nat[0].id subnet_id = aws_subnet.public[0].id tags = { Name = "nat-${var.env_name}" Environment = var.env_name } } # 4. 动态创建路由表：条件决定是否关联NAT网关 resource "aws_route_table" "private" { vpc_id = aws_vpc.main.id route { cidr_block = "0.0.0.0/0" nat_gateway_id = var.enable_nat_gateway ? aws_nat_gateway.main[0].id : "" } tags = { Name = "rtb-private-${var.env_name}" Environment = var.env_name } } # 5. 子网关联路由表（隐式依赖：route_table_id参数引用上面的资源） resource "aws_route_table_association" "private" { for_each = { for idx, subnet in aws_subnet.public : idx => subnet } subnet_id = each.value.id route_table_id = aws_route_table.private.id }

关键点解析：

• count = var.enable_nat_gateway ? 1 : 0让NAT网关成为可选组件；
• nat_gateway_id = var.enable_nat_gateway ? aws_nat_gateway.main[0].id : ""在路由表中条件注入NAT ID，当enable_nat_gateway=false时，nat_gateway_id为空字符串，Terraform会忽略该路由（因为0.0.0.0/0路由必须有有效目标）；
• for_each遍历aws_subnet.public，自动适配az_count变化的子网数量，无需手动维护索引。

4.3 环境层调用：用变量注入驱动差异化部署

在environments/dev/main.tf中调用模块：

# environments/dev/main.tf provider "aws" { region = "us-east-1" } # 调用networking模块 module "networking" { source = "../../modules/networking/vpc" env_name = "dev" region = "us-east-1" cidr_block = "10.10.0.0/16" enable_nat_gateway = false # 开发环境不需NAT az_count = 1 # 开发环境用1个AZ降低成本 } # 调用compute模块 module "compute" { source = "../../modules/compute/ec2" env_name = "dev" vpc_id = module.networking.vpc_id public_subnet_ids = module.networking.public_subnet_ids instance_type = "t3.micro" ami_id = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 }

而在environments/prod/main.tf中：

# environments/prod/main.tf module "networking" { source = "../../modules/networking/vpc" env_name = "prod" region = "us-east-1" cidr_block = "10.100.0.0/16" enable_nat_gateway = true # 生产环境必须NAT az_count = 3 # 生产环境3个AZ保障高可用 } module "compute" { source = "../../modules/compute/ec2" env_name = "prod" vpc_id = module.networking.vpc_id public_subnet_ids = module.networking.public_subnet_ids instance_type = "m5.large" # 生产环境更大实例 ami_id = "ami-0c55b159cbfafe1f0" }

所有环境差异，都收敛在main.tf的模块参数中，模块内部代码完全复用。这就是变量+条件带来的威力。

4.4 CI/CD集成：用Terraform Cloud实现自动化审批流

最后一步，把这套代码接入CI/CD。我们用Terraform Cloud（TFC）实现：

• environments/dev/的变更，terraform apply自动执行；
• environments/prod/的变更，terraform plan生成后，必须由两名管理员在TFC界面上点击“Apply”才执行；
• 所有plan输出自动存档，可追溯每次变更的详细差异。

TFC的terraform.tfvars配置：

# environments/prod/terraform.tfvars env_name = "prod" region = "us-east-1" # 密钥通过TFC变量管理，不在文件中

在TFC中设置Workspace变量：

• TF_VAR_db_password：标记为Sensitive，值来自AWS Secrets Manager
• TF_VAR_slack_webhook：用于发送部署通知

这样，开发人员只需git push，TFC自动检测到environments/prod/变更，运行plan，邮件通知审批人。整个流程无人值守，但关键操作有人把关，平衡了效率与安全。

5. 常见问题与避坑指南：那些只有踩过才懂的细节

5.1 变量相关高频问题

Q1：为什么terraform plan提示“Variable not set”？
A：检查变量加载顺序。最常见的原因是：

• 忘记创建terraform.tfvars或*.auto.tfvars文件；
• 文件名有空格或特殊字符（如prod.tfvars正确，prod config.tfvars错误）；
• 在子目录中执行terraform plan，但变量文件在父目录（Terraform只读当前目录及子目录的.tfvars）。
  实操技巧：用terraform console交互式调试变量：

$ terraform console > var.env_name "dev" > length(var.ingress_ports) 2

Q2：如何安全地覆盖默认变量？
A：永远用-var-file优先于环境变量。因为环境变量会污染shell会话，而-var-file是单次命令隔离的。CI/CD脚本中：

# 推荐：清晰、可审计 terraform apply -var-file=environments/prod/terraform.tfvars -auto-approve # 不推荐：环境变量易泄漏 export TF_VAR_env_name="prod" terraform apply -auto-approve

Q3：sensitive = true的变量为什么在terraform output中还是显示？
A：sensitive只对terraform plan和terraform apply的输出隐藏，terraform output默认仍显示。要隐藏输出，必须在output中也声明sensitive：

output "db_password" { value = var.db_password sensitive = true # 关键！必须显式声明 }

5.2 依赖相关致命陷阱

Q1：depends_on为什么没生效？
A：depends_on只控制资源创建顺序，不控制资源状态等待。比如：

resource "aws_rds_cluster" "main" { # ... 配置 } resource "aws_rds_cluster_instance" "reader" { depends_on = [aws_rds_cluster.main] # 错误！这不能保证cluster已就绪 }

正确做法是：用aws_rds_cluster的cluster_identifier作为aws_rds_cluster_instance的参数，建立隐式依赖；或用null_resource做健康检查。

Q2：为什么terraform destroy时资源销毁顺序不对？
A：Terraform销毁顺序是创建顺序的逆序，但受depends_on影响。如果A依赖B，销毁时B先于A销毁。但如果B没有显式依赖A，而A又持有B的ID（如S3 bucket policy引用bucket ID），销毁时可能报错。终极解决方案：用lifecycle块控制销毁行为：

resource "aws_s3_bucket_policy" "main" { bucket = aws_s3_bucket.main.id policy = data.aws_iam_policy_document.main.json lifecycle { prevent_destroy = true # 防止误删，必须手动注释掉才能destroy } }

5.3 条件逻辑的隐蔽雷区

Q1：count = 0后，资源状态消失了，但terraform state里还有记录？
A：count = 0会将资源标记为“已销毁”，但状态文件仍保留其历史。用terraform state list查看，会看到module.web.aws_instance.app[0]状态为orphaned。清理命令：

terraform state rm 'module.web.aws_instance.app[0]'

但注意：这会永久删除状态，确保资源在云上确实已销毁。

Q2：for_each的键变化导致资源重建？
A：是的！for_each的键是资源ID的一部分。如果键从"web"变成"web-server"，Terraform会认为这是新资源，销毁旧的，创建新的。避坑口诀：键必须稳定。我们用md5()哈希原始数据生成稳定键：

locals { stable_keys = { for item in var.security_rules : md5("${item.port}-${item.protocol}") => item } } resource "aws_security_group_rule" "ingress" { for_each = local.stable_keys # ... }

Q3：条件嵌套太深，代码难以维护？
A：立即提取到locals！Terraform没有函数，但locals就是你的函数。把三层嵌套的ternary写成：

locals { final_instance_type = module.compute.instance_type } resource "aws_instance" "app" { instance_type = local.final_instance_type }

然后在modules/compute/ec2/variables.tf里集中处理所有条件逻辑。模块是Terraform的封装单元，locals是模块内的封装单元。

5.4 综合故障排查速查表