Terraform vs Pulumi：2026 年基础设施即代码怎么选？

配置语言：HCL vs 真编程语言

HCL 的优势：专用 DSL，声明式设计

Terraform 用 HCL（HashiCorp Configuration Language），声明式 DSL，语法像 JSON 和 YAML 的混血儿。HCL 看起来限制多，但这恰恰是它的强项。声明式语法强制你描述”要什么”而不是”怎么做”，代码可读性高到运维和开发都能看懂。没有复杂的控制流，没有隐藏的副作用，一眼看穿资源依赖关系。

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  
  tags = {
    Name = "web-server"
  }
}

这段代码任何人都能读懂，包括刚入职的运维新人。学习曲线不陡，但也不浅——简单场景下很干净，复杂逻辑会让配置文件变成”配置地狱”。想抽象？得用 module。想复用？得写一堆 variable。想动态生成？得和 count/for_each 搏斗。

Pulumi 的诱惑：真编程语言，灵活但易失控

Pulumi 直接让你用 TypeScript、Python、Go、C#、Java，甚至 YAML（给不想写代码的人留了后门）。这意味着：

• IDE 原生支持：自动完成、类型检查、重构工具，开箱即用
• 标准库随便用：想读配置文件？fs.readFileSync。想调 API？fetch 或 axios。想写单元测试？Jest/pytest 拿来就用
• 复杂逻辑不费劲：循环、条件、函数、类，怎么顺手怎么来
• 复用代码更自然：npm/pip 上有海量库，不用重复造轮子

const server = new aws.ec2.Instance("web", {
    ami: "ami-0c55b159cbfafe1f0",
    instanceType: "t3.micro",
    tags: { Name: "web-server" },
});

表面上看差不多，但 Pulumi 的问题在于：你可以写循环、条件、函数调用，代码很快就会变成意大利面。两个月后你自己都看不懂当时写的逻辑。更别说交给团队维护了。

举个例子：你要给 10 个微服务创建 Kubernetes Deployment，每个服务的配置略有不同。Terraform 里你要么写 10 个 resource block，要么用 for_each 配合复杂的 map 变量，调试时只能盯着 plan 输出猜问题。Pulumi 里你直接写个循环，传参数，调函数，出问题了断点调试，IDE 告诉你哪里类型不对。

学习曲线：DSL 学习 vs 编程技能复用

Terraform 的 U 型曲线：

1. 入门简单：照着官方文档写几个 resource，跑个 terraform apply，能用
2. 中期痛苦：开始接触 count、for_each、dynamic、module，每个都有坑
3. 高级稳定：理解了 HCL 的设计哲学，知道什么该做什么不该做

Pulumi 的反 U 型曲线：

1. 入门有门槛：得懂一门编程语言，理解 Pulumi 的 SDK 和 resource model
2. 中期顺滑：编程技能直接复用，复杂逻辑照写不误
3. 高级灵活：可以写自定义 component、dynamic provider，甚至贡献 provider

关键区别：Terraform 要求你学一门新 DSL，Pulumi 要求你会一门编程语言。如果你的团队是 SRE/DevOps 背景，可能 HCL 更好接受。如果团队是软件工程师，Pulumi 上手更快——毕竟他们本来就写 TypeScript/Python/Go。

生态系统：成熟 vs 增长

Terraform 生态碾压级优势：

• Provider 数量：3000+ 官方和社区 provider，覆盖几乎所有云服务和 SaaS
• Registry 成熟：Terraform Registry 有大量经过实战检验的 module，拿来即用
• 社区庞大：Stack Overflow 上问题多，遇到坑基本能找到解
• 工具链完善：Terragrunt、Atlantis、Spacelift、env0 等工具专为 Terraform 设计

Pulumi 生态追赶中：

• Provider 数量：180+ provider，核心云服务（AWS/GCP/Azure/K8s）都有，但长尾 SaaS 支持不如 Terraform
• Crosswalk 库：AWS/Azure/GCP Crosswalk 提供高级抽象，比原始 API 更好用
• 桥接机制：可以直接桥接 Terraform provider（pulumi-terraform-bridge），理论上能用 Terraform 的 provider，但转换后的 API 经常有 bug，文档也跟不上
• 编程语言生态加成：可以用 npm/pip/go modules 管理依赖，发布私有 package

实话说，Terraform 生态更成熟。但 Pulumi 的桥接机制让这个差距不致命——虽然体验不如原生 provider 顺滑，核心场景已经覆盖得够好。

状态管理：Terraform State vs Pulumi Stack

两者都用状态文件跟踪资源，但实现细节不同。

Terraform State：

• 后端灵活：支持本地、S3、GCS、Azure Blob、Consul、Terraform Cloud 等后端
• 锁机制：用 DynamoDB（AWS）或其他后端实现状态锁，防并发冲突
• 迁移麻烦：terraform state mv、terraform import 是常见操作，但容易出错
• 敏感数据风险：state 文件里明文存敏感数据（密码、密钥），加密靠后端配置

Pulumi Stack：

• 多栈隔离：一个项目可以有多个 stack（dev/staging/prod），天然隔离
• 加密内置：敏感数据（secret）自动加密，基于 KMS 或 passphrase
• Pulumi Service：官方 SaaS 后端，免费版够小团队用，付费版有 RBAC、审计日志、CI/CD 集成
• 自托管后端：也支持 S3/GCS/Azure Blob，或者本地文件

Pulumi 的 stack 设计更现代，多环境管理更自然。Terraform 的 workspace 也能实现类似效果，但没那么直观。状态加密方面，Pulumi 默认加密 secret，Terraform 需要你自己配置后端加密。

团队协作：Terraform Cloud vs Pulumi Service

Terraform Cloud（HashiCorp 官方 SaaS）：

• 免费版限制：5 个用户，1 个并发运行，够小团队用
• 核心功能：Remote state、运行历史、审批工作流、策略即代码（Sentinel，付费功能）
• CI/CD 集成：VCS 集成（GitHub/GitLab/Bitbucket），PR 触发 plan，merge 触发 apply
• 定价：标准版 $20/用户/月，Plus 版 $70/用户/月

Pulumi Service（Pulumi 官方 SaaS）：

• 免费版限制：无限用户，3 个 stack，适合小项目
• 核心功能：Remote state、部署历史、审计日志、RBAC、策略即代码（CrossGuard）
• CI/CD 集成：GitHub Actions/GitLab CI/CircleCI 原生集成，或者 Pulumi Deployments（托管 CI/CD）
• 定价：Team 版 $75/月（10 stack），Enterprise 版定制

Pulumi Service 的免费版更慷慨（无限用户 vs 5 用户），但 stack 限制更紧（3 个 vs 理论上无限 workspace）。Terraform Cloud 的策略即代码（Sentinel）是付费功能，Pulumi 的 CrossGuard 在 Team 版就有。

两者都支持自托管：Terraform 可以用 Terraform Enterprise，Pulumi 可以用 Pulumi Business Critical（完全自托管）。Terraform plan 输出非常详细，清楚标注哪些资源会被创建/修改/删除，diff 格式易读。Pulumi preview 输出较简略，复杂变更时不如 Terraform 直观。

许可证争议：BSL vs Apache 2.0

2023 年 8 月，HashiCorp 把 Terraform 从 MPL 2.0 改成 BSL（Business Source License），禁止竞品用 Terraform 代码提供商业服务。这直接导致了 OpenTofu fork——Linux 基金会支持的开源分支，继续用 MPL 2.0。

影响：

• Terraform 本身免费：个人和企业使用不受影响，但不能拿它做托管服务
• OpenTofu 作为替代：完全兼容 Terraform 1.5.x，社区支持强劲，Spacelift/env0 等平台已支持
• 生态分裂风险：长期来看，OpenTofu 可能走出独立路线，与 Terraform 逐渐分化

Pulumi 一直是 Apache 2.0 许可证，开源友好，没有类似争议。如果你在意许可证自由度，Pulumi 或 OpenTofu 是更安全的选择。

性能和速度

Terraform：

• Plan/Apply 速度取决于 provider 实现，大规模资源（1000+ resource）时 plan 可能很慢
• 并行度可调（-parallelism 参数），但默认 10 并发，保守设计

Pulumi：

• 基于编程语言运行时，理论上可以更灵活地控制并发和异步操作
• Preview/Up 速度与 Terraform 相当，大规模场景下没有明显优势
• 因为是编程语言，可以写异步代码、并行创建资源，但需要手动控制

性能上两者差不多，都不是瓶颈。真正的速度瓶颈在云 API 调用和资源创建时间。

功能对比表

适用场景：什么时候选谁？

选 Terraform（或 OpenTofu）的理由：

• 团队主要是运维背景，习惯声明式配置，不想写”真代码”
• 需要覆盖长尾 SaaS/云服务，Terraform 的 3000+ provider 是刚需
• 已有大量 Terraform 代码，迁移成本高
• 用 Terragrunt/Atlantis 等工具，生态依赖深
• 在意开源纯度，选 OpenTofu 分支
• 成熟稳定优先，不想踩新工具的坑
• 预算有限，开源免费方案

选 Pulumi 的理由：

• 团队是软件工程师背景，精通 TypeScript/Python/Go
• 需要复杂逻辑、动态生成、高级抽象，HCL 写起来痛苦
• 想用标准编程工具（IDE、linter、测试框架）提升开发效率
• 多环境管理需求强，Pulumi 的 stack 设计更友好
• 在意许可证自由度，Apache 2.0 更安全
• Kubernetes 为主，Pulumi 的 K8s 支持更现代
• 愿意为更好的开发体验付费

混合场景：

如果你的团队既有运维又有开发，可以考虑：

• 基础设施层用 Terraform（网络、账户、IAM），稳定且不常改
• 应用层用 Pulumi（Kubernetes、微服务配置），需要频繁迭代和复杂逻辑

选择建议

2026 年了，Terraform 和 Pulumi 都是成熟工具，不存在”一个明显更好”。选型核心看团队技能栈：

• 如果你的团队主要是传统运维，或者已有大量 Terraform 代码，继续用 Terraform（或迁移到 OpenTofu）。HCL 的学习成本不算高，生态成熟度是最大优势。HCL 的”局限性”恰恰是它的优势——强制你写出可维护的代码。
• 如果你的团队主要是软件工程师，或者在构建复杂平台工程体系，Pulumi 是更好的选择。编程语言的灵活性、类型安全、测试能力，会在长期项目中节省大量时间。
• 如果你在起步阶段，不确定未来规模，Pulumi 的免费版（无限用户）和桥接 Terraform provider 的能力，让你可以先用着，不行再换。

最后提醒：不管选哪个，状态管理、CI/CD 集成、策略即代码都得配上。IaC 不只是写配置，而是整个基础设施工程化的起点。工具是为团队服务的，不是团队为工具服务。选你的团队能用好的，比选”最好的”更重要。