Pulumi

概述 去年年底接手一个项目：某出行平台的云基础设施代码库，Terraform HCL 写了 3000 多行，分了 40 多个模块，循环引用 3 处，for_each 嵌套两层 dynamic block 到没人看得懂。新来的运维改了一行 tags，terraform plan 输出 847 行变更，其中 600 行是"无实际影响但状态会更新"。他不敢 apply，我也看不懂那 847 行。 这不是个例。我在多个项目里见过同样的剧本：HCL 在 500 行以内很好用，超过 1000 行就开始失控，2000 行以上就是"只有写的人敢碰"的炸弹。原因不复杂——HCL 是领域专用语言（DSL），设计目标是"声明式配置"，不是"工程化代码"。它没有函数（只有 module），没有异常处理，没有类型推断，测试要靠第三方工具（如 Terratest）从外部驱动。 Pulumi 换了个思路：用你已经在用的编程语言（Go、Python、TypeScript 等）写基础设施。听起来只是"换种语法"，但它改变的是整个工程实践——你可以写单元测试、用 IDE 跳转定义、用包管理器复用代码、甚至把 IaC 嵌入应用里通过 API 驱动部署。 这篇文章不讲"Pulumi 比 Terraform 好"这种废话。我讲的是：在什么场景下你应该考虑迁移，迁移时做哪些架构决策，以及我踩过的 5 个坑。所有结论来自我在某出行平台和某电商平台的基础设施改造实践，数据脱敏但结构和逻辑保留。 为什么 HCL 写到 3000 行会"烂掉" 先说清楚问题出在哪，不然迁移决策就是拍脑袋。 HCL 的设计哲学与工程化冲突 HCL 的核心是声明式——你告诉 Terraform"期望状态是什么样"，引擎负责把现实对齐到期望。这个模型在 500 行以内很优雅：一段 VPC 配置、几个安全组、一个 RDS 实例，读起来像配置文件，改起来也直观。 但工程规模上去后，HCL 的设计约束变成短板： 场景 HCL 的做法 编程语言的做法 根据环境创建不同资源 count = var....