Terraform vs Pulumi：IaC 工具对比 2026
基础设施即代码（IaC）已经从十年前的边缘实践成长为云原生时代的默认工程范式。无论是初创公司还是金融机构，团队都在用代码描述网络、计算、存储、密钥与数据库，让基础设施像应用一样进入版本管理、Code Review、流水线发布。在 IaC 工具中 Terraform 长期占据头部位置，市场份额接近八成；而 Pulumi 自 2018 年问世以来凭借"用真正的编程语言写基础设施"的理念吸引了一批拥护者。2023 年 HashiCorp 宣布 Terraform 切换到 BSL 许可证后，社区分叉出 OpenTofu，又一次重塑了选型考量。本文从语言哲学、状态管理、模块化、多云适配、学习曲线、OpenTofu 走向、漂移检测以及与 GitOps 的整合八个维度逐一对比，给出 2026 年的实战建议。
声明式 HCL 与命令式编程语言的根本分歧
Terraform 使用专属配置语言 HCL（HashiCorp Configuration Language）。语法接近 JSON 但更人性化，原生支持表达式、变量、循环、条件，重点是"声明期望状态"。开发者描述要存在哪些资源、它们的属性是什么，剩下交给 Terraform 做差异计算与并行执行。这种声明式风格非常适合静态基础设施，模板与配置高度对齐。
Pulumi 反其道而行，用 TypeScript、Python、Go、C#、Java、YAML 等真实编程语言描述基础设施。开发者通过调用类与函数生成资源对象，背后的引擎再把对象图转成执行计划。这种命令式风格让你能复用语言的全部能力——类型系统、IDE 智能提示、单元测试、包管理、抽象层都能直接拿来用。
两种风格各有取舍。HCL 的限制反过来是优点：因为不能任意写代码，配置更可预测、审查更直观、新人更容易上手。Pulumi 的灵活性可能让 IaC 变成"普通代码"，丧失 IaC 该有的可重放性，因此团队需要约定模式与代码规范来抑制滥用。如果团队主体是基础设施工程师、SRE，HCL 更对胃口；如果团队由产品工程师组成、希望基础设施融入应用代码，Pulumi 更顺畅。
状态管理：远端后端与版本控制
IaC 工具都需要一份 state 来记录"上次创建的资源是什么"。Terraform 的 state 文件默认写在本地 terraform.tfstate，生产中必须切换到远端后端，比如 S3 加上 DynamoDB 锁、阿里云 OSS 加上 TableStore、Azure Storage、GCS、Terraform Cloud 等。远端后端解决了多人协同的并发写入问题，也让备份与审计落地。
Pulumi 默认使用 Pulumi Cloud（前身 Pulumi Service）作为后端，免费版支持小团队，付费版提供 RBAC、审计、策略检查、环境变量管理。如果不想依赖 SaaS，也可以用 S3、Azure Blob、GCS 自托管 state。state 文件用对称密钥加密，配合 Pulumi 的 secrets provider 可以集成 AWS KMS、Azure Key Vault、HashiCorp Vault。
实战中 state 是最容易出事的地方：误删、并发覆盖、密钥外泄都会带来生产事故。最佳实践是：开启版本控制与跨区域复制；apply 前必须取得分布式锁；敏感字段加密；定期备份并测试恢复流程；不在 git 仓库中提交任何 state 文件。无论选哪种工具，把 state 当作核心资产对待都是必修课。
模块化：Module 与 ComponentResource
Terraform 通过 Module 实现复用。Module 是一组资源、变量、输出的封装，可以发布到 Terraform Registry、Git 仓库、S3 等位置，团队按版本号引用。社区提供了大量公共 Module，例如 terraform-aws-modules、terraform-aliyun-modules，覆盖 VPC、EKS、RDS 等常见场景。Module 的接口由变量与输出定义，足够稳定。
Pulumi 把同样的概念称为 Component Resource。它本质是一个继承自 ComponentResource 的类，把内部资源封装成一个抽象单元。由于宿主语言完整，Component 可以暴露方法、属性、事件，与普通编程的对象模型一致。这种抽象在写复杂中台基础设施（多租户隔离、按需创建数据库等）时非常自然。
如果你的团队需要发布"一键部署模板"给业务线使用，Terraform Module 的成熟度更高，文档与版本管理基础设施齐备。如果你做平台工程，希望把基础设施作为内部 SDK 暴露给多个产品线消费，Pulumi Component 在抽象能力上更强大。
多云适配与 Provider 数量
Terraform Registry 是当前最大的 IaC 生态枢纽，截至 2026 年初官方与社区 Provider 已超过三千个，覆盖所有主流公有云、私有云、监控平台、SaaS、CDN、CI 系统。中文资料里 AWS、Azure、GCP、阿里云、腾讯云、华为云、火山引擎都能直接找到 Provider。
Pulumi 的 Provider 数量虽然较少但增长很快，并且许多 Provider 是基于 Terraform Provider 自动生成的（pulumi-tf-provider-bridge）。这意味着在 AWS、Azure、阿里云这类大型云上，Pulumi 与 Terraform 的能力非常接近。少数小众 Provider 可能晚一两个月出现在 Pulumi 端。
对于多云项目，Terraform 的 Provider 数量与社区 Module 的丰富度仍是最大优势。但若团队本就采用 TypeScript 或 Go 作为主要语言，Pulumi 能让基础设施代码与应用代码共享类型与 lint 规则，整体一致性更好。两个工具甚至可以在一个组织内并存，通用基础设施由 Terraform 统管，产品线特定逻辑用 Pulumi 表达。
学习曲线与上手时间
Terraform 的入门曲线相对平缓。HCL 语法只有十几个关键字，run 模型只有 init、plan、apply、destroy。新人一周就能写出像样的小项目，第二周开始接触 Module 与 Workspace。难点出现在大规模管理：状态拆分、跨账户权限、Workspace 与 Environment 的取舍、动态生成资源等都需要经验。
Pulumi 对会写代码的人门槛极低——熟悉 TypeScript 或 Python 就能直接读懂示例。但要写出可维护的 IaC 代码反而难度更高，因为编程语言无所不能，新人很容易把基础设施代码写成一堆条件分支。团队需要建立 lint 规则、Pre-commit 钩子、Code Review 模板。
从招聘市场看 Terraform 工程师人数多于 Pulumi 工程师，国内企业 JD 也以 Terraform 为主。学习资源、培训课程、认证体系都更成熟。Pulumi 的学习曲线对纯应用开发者更友好，对纯运维背景的团队反而需要补编程功底。
OpenTofu 分叉与许可证演变
2023 年 8 月，HashiCorp 宣布 Terraform 切换到 Business Source License（BSL），禁止与 HashiCorp 商业产品竞争的厂商分发 Terraform。云厂商与开源社区震动，OpenTF 联盟随即成立，宣布分叉。同年 OpenTF 加入 Linux Foundation，更名为 OpenTofu。OpenTofu 1.6 在 2024 年初正式发布，命令名 tofu，状态文件、HCL、Provider 与 Terraform 完全兼容。
2025-2026 年 OpenTofu 加入了 Provider 端到端加密、早期变量评估、动态 Provider 等独立特性，迭代速度并不亚于官方 Terraform。GitLab、阿里云、腾讯云等多家 SaaS 与云厂商已经在自家平台默认集成 OpenTofu。许多企业出于许可合规考虑，把 CI/CD 中的 terraform 命令换成了 tofu，迁移成本接近于零。
Pulumi 一直采用 Apache 2.0 许可证，没有此类风险。某种意义上 BSL 事件让 Pulumi 多了一批关注者，但 OpenTofu 的出现让"想要纯开源 Terraform"的需求得到了内部解决，整体格局并未发生剧烈洗牌。
漂移检测与策略即代码
漂移指实际云资源与 IaC 代码描述不一致——可能是有人在控制台直接修改了 Security Group，也可能是云厂商自动注入的字段。Terraform 用 plan 命令检测，并显示差异；Pulumi 的 preview 命令同理。商业 SaaS 平台 Terraform Cloud、Pulumi Cloud、Spacelift、Env0、Atlantis 都内置定时漂移检测与告警。
策略即代码（Policy as Code）是大型组织避免误用 IaC 的关键。HashiCorp 提供 Sentinel（商业版）与开源 OPA（Open Policy Agent）集成；Pulumi 提供 CrossGuard，可以用 TypeScript 或 Python 编写策略。常见策略例子：所有 S3 bucket 必须开启加密、生产环境不允许公网 IP、所有数据库实例必须有备份。这些规则在 PR 阶段执行，能将合规问题扼杀在合并前。
实战中，把漂移检测放进每日定时任务、把策略检查放进 PR 流水线，是当前最被验证的做法。结合 GitOps 工具（Atlantis、Terragrunt、Pulumi Deployments）可以做到从 Pull Request 到生产应用全自动。
2026 年选型建议与组合策略
如果团队主体是基础设施工程师、需要长期管理跨云资源、追求最大社区生态与最丰富 Module 库，Terraform 仍是首选；想规避 BSL 许可争议时，可以无痛切换到 OpenTofu。如果团队由全栈工程师组成、希望用熟悉的编程语言写基础设施、需要细粒度抽象与单元测试，Pulumi 在产品速度与代码复用上更有优势。
混合策略也越来越常见：用 Terraform/OpenTofu 管 VPC、IAM、跨账户共享资源，用 Pulumi 管业务线的 Lambda、ECS Service、数据库实例。两者通过 remote state 数据源互相引用，团队各取所长。无论选哪一个，都不要忽视基本功：state 远端后端、变更评审、漂移监控、策略检查、GitOps 流水线、敏感数据加密。这些做扎实，工具的差异其实可以容忍。
最后提醒一点：IaC 不是终点，而是平台工程的起点。再优秀的工具也代替不了清晰的资源命名规范、合理的环境拆分、完善的灾备演练。以工程化心态把 IaC 嵌进研发流程，才能真正享受到"基础设施可重放"的红利。
常见问题
OpenTofu 和 Terraform 现在到底什么关系？
OpenTofu 是 Linux Foundation 在 2023 年从 Terraform 1.5 分叉出的开源版本，因 HashiCorp 切换到 BSL 许可证而诞生。它由社区驱动，Provider、State 文件、HCL 语法与 Terraform 高度兼容，命令名为 tofu。从 1.6 起 OpenTofu 已加入 Provider 加密、早期评估等独立功能。商业用户和合规敏感的团队倾向 OpenTofu，而依赖 Terraform Cloud 的用户继续使用官方版本。
Pulumi 用 TypeScript 写代码会不会被滥用？
是真实风险。命令式语言的灵活性意味着开发者可以写出难以审查的循环、条件、外部调用，而 IaC 的核心价值是可预测和可审计。最佳实践是限制单文件长度、用纯函数生成资源、避免在代码里读取外部 HTTP，并通过 PR 审查与策略即代码（Pulumi CrossGuard、OPA）保证规范。这样既享受类型与 IDE 的便利，又保留 IaC 的安全边界。
state 文件丢了怎么办？
这是 IaC 最严重的事故之一。state 文件丢失意味着工具无法关联资源，再次 apply 可能创建重复资源。Terraform 与 Pulumi 都建议把 state 放到带版本控制的远端后端（S3 + DynamoDB、阿里云 OSS、Azure Storage、Pulumi Cloud），并启用 versioning 与异地复制。即便丢失，也可用 import 命令将云上资源重新挂回，但这是体力活，最好提前演练。
漂移检测怎么做才有效？
Terraform 用 plan 命令对比 state 与云上实际，Pulumi 用 preview 实现同样能力。在生产环境建议把漂移检测放进 CI/CD 流水线定期运行，结合 Slack/钉钉通知。商业平台 Terraform Cloud、Pulumi Cloud、Spacelift、Env0 都内置漂移仪表板。检测到漂移后第一步是评估是否合规变更，再决定 reset 或更新代码。
多云项目应该选哪个？
两者都支持主流公有云、私有云与 SaaS。Terraform 的 Provider 数量最多（超过三千个），AWS、Azure、GCP、阿里云、腾讯云、华为云均有官方 Provider；Pulumi 几乎覆盖同等数量，因为它内部很多 Provider 是从 Terraform 生成的。差异更多体现在工作流：Terraform 适合大型基础设施团队的统一管控，Pulumi 适合开发者深度参与基础设施的产品团队。