Terraform vs Pulumi 2026：IaC 工具怎么选

Terraform vs Pulumi：2026 年做基础设施即代码，开发者到底该选谁？

🇺🇸
Read in English: Terraform vs Pulumi in 2026: Which Should Developers Actually Choose for IaC?

2023 年 8 月的一个下午，一位在某跨境电商公司做 DevOps 的朋友给我发来消息：”HashiCorp 把 Terraform 的 license 改了，我们整个基础设施都搭在上面，你说我要不要慌？”

他不是唯一一个慌的人。HashiCorp 宣布将 Terraform 从 MPL 2.0 切换到 BSL（Business Source License）之后，整个开源社区炸了锅。简单说，BSL 意味着竞争对手不能再拿 Terraform 源码去做商业化产品。对大多数终端用户来说，日常使用不受影响，但那种”有一天规则会不会再变”的不安全感，一直扎在心里。

紧接着，Linux Foundation 出面托管了 OpenTofu，一个从 Terraform 最后一个开源版本 fork 出来的项目，承诺永远保持开源。社区分裂、工具 fork、license 博弈，这些事情在开源世界并不罕见，但当它发生在你每天赖以为生的基础设施工具上时，任何人都会停下来重新审视自己的技术栈。

而就在这个节骨眼上，越来越多的人开始认真看向另一个名字：Pulumi。

当 HCL 成为一种信仰

要理解 Terraform 为什么能统治 IaC 领域这么多年，你得先理解 HCL。

HCL（HashiCorp Configuration Language）是一种声明式的领域特定语言。你不需要告诉它”先创建 VPC，再创建子网，再挂载路由表”，你只需要描述你想要的最终状态，Terraform 会帮你算出从当前状态到目标状态需要做什么。这种思路非常优雅，也非常安全。你写的是”世界应该是什么样子”，而不是”怎么一步步把世界改成那个样子”。

我见过太多团队因为 Terraform 的确定性而爱上它。一个负责管理三朵云的运维团队，用 Terraform 写了几百个 module，覆盖了 AWS、Azure、GCP 上的所有资源。每次变更都走 terraform plan，看清楚差异再 apply，出问题就 state 回滚。一切都有迹可循，一切都可审计。

Terraform 的 provider 生态更是它最深的护城河。截至今天，Terraform Registry 上有数千个 provider，从主流云厂商到小众 SaaS，几乎你能想到的任何服务都有人写好了 provider。这意味着，不管你的技术栈有多奇葩，大概率都能在 Terraform 的世界里找到位置。

但 HCL 也有让人抓狂的时刻。

当你需要在基础设施代码里实现复杂逻辑的时候，HCL 的表达力就显得捉襟见肘了。想做一个条件判断？count 和三元表达式勉强能用。想做循环？for_each 可以，但嵌套起来可读性急剧下降。想抽象一段可复用的逻辑？Module 是标准答案，但 module 的接口设计、变量传递、输出引用，写多了你会觉得自己在用一门”五十步笑百步”的编程语言，它明明不是编程语言，却非要你用编程语言的思维去组织代码。

一个后端开发者曾经跟我吐槽：”我用 Python 三行能解决的事，HCL 要写二十行，还得查半天文档确认这个语法到底支不支持。”

当开发者说”我想用自己的语言”

Pulumi 的出现，恰恰就是对这种痛点的回应。

Pulumi 的核心理念是：基础设施代码就是代码。不是”像代码一样”的配置文件，不是某种受限的 DSL，而是真真正正的编程语言。你可以用 TypeScript、Python、Go、C#、Java，甚至 YAML 来定义基础设施。

这意味着什么？

想象一下，你是一个全栈开发者，后端用 TypeScript 写 Node.js 服务，前端用 React。现在要给项目搭基础设施，比如一个 ECS 集群、一个 RDS 数据库、一套 IAM 策略。如果用 Terraform，你需要学一门新语言（HCL），理解它独特的模块系统，习惯它的变量传递方式。但如果用 Pulumi，你直接打开 VS Code，npm init，然后用你每天都在写的 TypeScript 来描述基础设施。IDE 的自动补全、类型检查、重构工具全部能用。写个函数抽象重复逻辑？随手就来。要根据环境变量动态生成资源配置？一个 if 语句搞定。

我认识一个三人创业团队，后端全是 Python 出身，之前用 Terraform 管理 AWS 资源时总觉得别扭。切到 Pulumi 之后，他们写基础设施代码的速度翻了一倍，因为他们不再需要”翻译”，不用再把脑子里的 Python 逻辑翻译成 HCL 语法。他们直接用 Python 的 class 来封装一组相关资源，用 decorator 来做标签管理，用 pytest 来测试基础设施逻辑。一切都是他们熟悉的世界。

Pulumi 也支持声明式的方式工作。你同样是描述期望状态，引擎帮你 diff 和执行。只不过，表达这个期望状态的方式，从一种受限的 DSL 变成了图灵完备的编程语言。

状态管理：谁来保管你的真相之源

IaC 工具最核心的概念之一是状态（state）。状态文件记录了”基础设施现在是什么样子”，这是工具计算变更计划的基础。状态管理没做好，轻则 drift 告警满天飞，重则误删生产资源。

Terraform 的状态管理经历了从本地文件到远端存储的演进。早期大家把 terraform.tfstate 往 S3 桶一扔就完事，后来有了状态锁定（通过 DynamoDB），再后来 Terraform Cloud 提供了一站式的远端状态管理、团队协作、策略即代码（Sentinel）等能力。如果你不想用 Terraform Cloud，也可以用开源的 backend（S3、GCS、Azure Blob 等），但你得自己搞定锁机制和权限控制。

Pulumi 从一开始就提供了 Pulumi Cloud 作为默认的状态后端。它处理状态存储、加密、并发控制、变更历史、团队权限这一整套事情。当然，Pulumi 也支持自托管状态存储（S3、Azure Blob、本地文件系统），但官方显然更希望你用他们的云服务。

这里有个微妙的差异。Terraform 生态里，你可以完全不碰 HashiCorp 的任何商业产品，纯粹用开源工具链跑完整个流程。而 Pulumi 虽然引擎开源，但如果你不用 Pulumi Cloud，自托管的状态管理体验会打一些折扣。这不是说不能用，只是你需要自己补上 Pulumi Cloud 免费帮你处理的那些事情。

一张表说清楚核心差异

当信息太多的时候，一张表能帮你快速定位关键差异：

维度	Terraform	Pulumi
语言	HCL（声明式 DSL）	TypeScript / Python / Go / C# / Java / YAML
状态管理	本地文件 / S3 / Terraform Cloud	Pulumi Cloud / S3 / 本地文件
Provider 生态	数千个，覆盖极广	较少但增长中，可桥接 Terraform provider
学习曲线	需要学 HCL，对纯运维友好	用熟悉语言上手快，对开发者友好
逻辑表达	受限（count / for_each / 三元表达式）	完整编程语言能力（循环/函数/类/包）
测试	有限（terraform test，较新）	原生支持单元测试、集成测试
定价	CLI 免费开源；Terraform Cloud 按资源数收费	CLI 免费开源；Pulumi Cloud 个人免费，团队按资源数收费
License	BSL 1.1（2023 年起）	Apache 2.0
适合团队	大型运维团队、多云环境、已有 HCL 积累	开发者主导团队、需要复杂逻辑、偏好通用语言

但表格只能告诉你”是什么”，无法告诉你”感觉如何”。真正的选型决策往往发生在那些表格装不下的场景里。

生态这件事，不只是数量

Pulumi 有一张隐藏的牌：它可以桥接 Terraform 的 provider。通过 Pulumi 的 Terraform Bridge，大量 Terraform provider 可以被直接拿来在 Pulumi 里用。这意味着 Terraform 生态的广度，Pulumi 用户也能间接享受。

但”桥接”和”原生”终究不是一回事。桥接的 provider 偶尔会有版本滞后、类型定义不完整、文档缺失的问题。当你踩到一个边缘 case 时，debug 的路径会更长，你得搞清楚问题是出在 Pulumi 这一层还是底下的 Terraform provider 那一层。

而 Terraform 的原生 provider，经过多年打磨，文档详尽、社区问答丰富、踩坑贴遍地都是。当你在凌晨三点排查一个生产环境的问题时，能不能在 GitHub Issues 或 Stack Overflow 上五分钟内找到答案，这种差距是实实在在的。

定价的隐含逻辑

两家的 CLI 工具都是免费开源的，你完全可以不花一分钱使用它们。

区别在于云服务。Terraform Cloud 的免费层给你远端状态存储和基本的团队协作，付费版按管理的资源数量收费，加上 Sentinel 策略、SSO 等企业功能。Pulumi Cloud 的个人版也是免费的（有资源数量上限），团队版同样按资源数收费。

一个值得留意的趋势是：在 HashiCorp 被 IBM 收购之后（2024 年），Terraform Cloud 的企业定价策略变得更加”IBM 化”，倾向于打包企业级功能，面向大客户。而 Pulumi 作为一家相对年轻的公司，定价策略更灵活，对中小团队更友好一些。

不过，定价这件事很少是选型的决定性因素。除非你的规模大到管理成千上万个资源，否则两家的云服务费用都不会成为你的预算瓶颈。真正昂贵的永远是人力成本。你的团队在哪个工具上更高效，哪个就更”便宜”。

OpenTofu：房间里的第三个人

讨论 Terraform vs Pulumi，绕不开 OpenTofu。

OpenTofu 是 Terraform 社区对 BSL 变更的直接回应。它维护了与 Terraform 的 API 兼容性，并承诺保持 MPL 2.0 开源协议。如果你的核心焦虑是 license 风险，OpenTofu 是一个不需要迁移技术栈的解决方案，你的 HCL 代码、module、provider 几乎可以无缝切过去。

但 OpenTofu 面临的挑战也很现实。分叉之后的社区发展速度、与 Terraform 后续版本的功能差异如何处理、谁来持续投入维护，这些问题都需要时间来回答。截至 2026 年，OpenTofu 已经有了自己的稳定版本和独立功能，但在使用者基数和企业采纳率上还在追赶。

所以问题变成了三选一：留在 Terraform（接受 BSL）、迁移到 OpenTofu（保留 HCL 生态）、还是切换到 Pulumi（换一种范式）。

谁该选 Terraform

如果你的团队符合以下描述，Terraform（或 OpenTofu）大概率是更稳妥的选择：

你们有一个独立的基础设施/平台工程团队，他们不一定是软件开发者出身，更多是运维、SRE 背景。HCL 对他们来说已经是母语，他们积累了大量的 module 库，CI/CD 流水线围绕 terraform plan 和 terraform apply 构建。迁移成本是真实的，而且你们的基础设施横跨多个云厂商，依赖大量小众 provider。

在这种场景下，Terraform 的价值不在于它”更好”，而在于它”更成熟”。你踩过的坑有人踩过，你遇到的问题有人解答过，你需要的集成有人写过。这种生态成熟度带来的效率，是任何新工具短期内很难复制的。

另一个常见场景是合规要求严格的行业（金融、医疗）。Terraform 的变更流程天然适合审计，声明式的代码加上 plan 输出、state 历史，构成一条完整的审计链。审计员看得懂 plan 里”将要创建什么、将要销毁什么”，这比解读一段 TypeScript 程序的执行结果要直观得多。

谁该选 Pulumi

如果你的团队是这个画像，Pulumi 可能会让你们如鱼得水：

你们是一个开发者主导的团队，基础设施由写业务代码的那帮人自己管（所谓”you build it, you run it”）。大家对 TypeScript 或 Python 比对任何 DSL 都熟。你们的基础设施逻辑有很多动态性，比如根据微服务数量自动生成资源、根据环境配置矩阵组合不同的部署拓扑、需要在基础设施代码里调用外部 API 获取参数。

在这种场景下，Pulumi 的优势是摧枯拉朽的。你不需要在”基础设施语言”和”业务语言”之间来回切换。你可以把基础设施代码和应用代码放在同一个 monorepo 里，共享类型定义，共享 utility 函数，甚至跑同一套 CI 流程。对这类团队来说，HCL 不是”简洁的声明式语言”，而是一个”多余的认知负担”。

还有一类场景特别适合 Pulumi：当你的基础设施本身就是产品的一部分。比如你在做一个 PaaS 平台，需要为每个租户动态创建隔离的基础设施资源。这种需求用编程语言表达极其自然，用 HCL 则需要大量的 workaround。