如何解读Terraform循环错误信息以定位循环引用？

错误标记含义速查 #

Terraform循环错误里的括号标记对应资源的处理状态，是定位问题的关键：

• (expand)：处理动态资源（比如用for_each/count生成的资源、模块、变量）时，正在展开计算实际要创建/更新的实例集合，属于正常过程状态，不是错误本身。
• (destroy)：该资源会被销毁，通常是配置变更触发了资源重建，或依赖关系断裂导致资源不再需要。
• (destroy deposed [哈希值])：Terraform的「资源替换保护」机制——当资源需要被替换时，旧资源会先被标记为deposed（哈希是旧资源的唯一标识），等新资源创建完成后再销毁，避免服务中断。

循环错误定位步骤 #

1. 拆分资源列表：把错误里的逗号分隔资源拆成独立条目，找出重复出现的资源（循环的核心是互相依赖，同一资源会在链条中多次出现）。
2. 追踪依赖链路：从重复资源出发，梳理资源/模块之间的依赖关系——比如A依赖B，B依赖C，C又依赖A，形成闭环。
3. 聚焦模块交互：循环错误大多出现在跨模块依赖中，重点检查模块输入输出的引用逻辑。

你的错误实例分析 #

给出的循环链条核心涉及两个模块的交互：

• module.cloudrun：包含api/admin两个Cloud Run服务及其IAM策略
• module.loadbalancer：包含Cloud Run对应的区域网络端点组（cloudrun_endpoint）、变量cloudrun_services、本地值cloudrun_services

核心循环链路（简化版） #

module.loadbalancer.var.cloudrun_services (expand)
→ module.cloudrun (close)
→ module.cloudrun["api"].google_cloud_run_service_iam_policy.noauth
→ module.loadbalancer.google_compute_region_network_endpoint_group.cloudrun_endpoint["api"]
→ 绕回cloudrun模块的服务/IAM策略，形成闭环

排查方向 #

• 检查module.loadbalancer的var.cloudrun_services是不是直接引用了module.cloudrun的输出值？
• 同时module.cloudrun的IAM策略（google_cloud_run_service_iam_policy.noauth）是不是又依赖了module.loadbalancer的资源（比如负载均衡的端点组、IP）？
• 动态资源的依赖逻辑是否搞反：应该是负载均衡端点组依赖Cloud Run服务，而不是Cloud Run服务/策略依赖负载均衡资源。

内容的提问来源于stack exchange，提问作者hallvors