IaC 2026 工具对比：Terraform / OpenTofu / Pulumi / CDK
基础设施即代码（Infrastructure as Code，IaC）从十年前的边缘实践成长为 2026 年云原生工程的默认范式。无论是金融、互联网、制造、政务，团队都在用代码描述网络、计算、存储、密钥与数据库，让基础设施像应用代码一样接受版本管理、Code Review、流水线发布。在 IaC 工具中 Terraform 长期占据头部位置，但 2023 年 HashiCorp 切换到 BSL 许可证后社区分叉出 OpenTofu，再加上 Pulumi 的"用真实编程语言写基础设施"路线，以及 AWS 主推的 CDK，2026 年的 IaC 战场比以往更热闹。本文从声明式与命令式、OpenTofu 分叉、状态管理、多云支持、模块化、学习曲线、CI/CD 整合与中国云厂商八个维度系统对比这四款主流工具，帮助决策者做出更稳的选型。
声明式 HCL 与命令式编程语言的根本分歧
Terraform 与 OpenTofu 都使用 HashiCorp Configuration Language（HCL）。这是一种声明式 DSL，语法接近 JSON 但更人性化，原生支持表达式、变量、循环、条件，重点是"声明期望状态"。开发者描述要存在哪些资源、它们的属性是什么，剩下交给引擎做差异计算与并行执行。这种风格非常适合静态基础设施，模板与配置高度对齐，新人上手快。
Pulumi 反其道而行，用 TypeScript、Python、Go、C#、Java、YAML 等真实编程语言描述基础设施。开发者通过实例化类与调用函数生成资源对象，背后的引擎再把对象图转成执行计划。AWS CDK 也属于这一阵营，用 TypeScript、Python、Java、C#、Go 编写 Construct，再合成 CloudFormation 模板。命令式风格让你能复用语言全部能力——类型系统、IDE 智能提示、单元测试、包管理、抽象层都直接可用。
两种风格各有取舍。HCL 的限制反过来是优点：因为不能任意写代码，配置更可预测、审查更直观、新人上手成本低。Pulumi/CDK 的灵活性可能让 IaC 变成"普通代码"，需要额外约束才不会失控。如果团队主体是基础设施工程师与 SRE，HCL 更对胃口；如果团队由产品工程师组成、希望基础设施融入应用代码，Pulumi 或 CDK 更顺畅。
OpenTofu 分叉与许可证演变
2023 年 8 月 HashiCorp 宣布 Terraform、Vault、Consul 等核心产品切换到 Business Source License（BSL），禁止与 HashiCorp 商业产品竞争的厂商分发这些项目。云厂商与开源社区震动，OpenTF 联盟随即成立宣布分叉，同年 OpenTF 加入 Linux Foundation 改名 OpenTofu。OpenTofu 1.6 在 2024 年初正式发布，命令名 tofu，状态文件、HCL、Provider 与 Terraform 完全兼容。
2025 到 2026 年 OpenTofu 加入了 Provider 端到端加密、状态加密、早期变量评估、动态 Provider、Stacks 等独立特性，迭代速度并不亚于官方 Terraform。GitLab、Spacelift、阿里云、腾讯云、Env0 等多家 SaaS 与云厂商已默认集成 OpenTofu。许多企业出于许可合规担忧，把 CI/CD 中的 terraform 命令换成 tofu，迁移成本接近零。
IBM 在 2025 年收购 HashiCorp 后，社区一度担忧 Terraform 走向。从目前看 IBM 维持现有 BSL 模式，没有更激进的限制，但许多企业仍把 OpenTofu 作为长期主力。Pulumi 与 CDK 一直是 Apache 2.0/MIT 许可证，没有此类风险。整体格局是 Terraform 与 OpenTofu 并行，企业按合规需要选择。
状态管理：远端后端与版本控制
IaC 工具都需要 state 来记录"上次创建的资源是什么"。Terraform/OpenTofu 默认写本地 terraform.tfstate，生产中必须切换到远端后端：AWS S3 + DynamoDB 锁、Azure Blob、GCS、阿里云 OSS + TableStore、Terraform Cloud、Spacelift。OpenTofu 1.7 起支持原生 State 加密，让敏感字段不再以明文存储。
Pulumi 默认使用 Pulumi Cloud（前 Pulumi Service），免费版支持小团队，付费版提供 RBAC、审计、策略检查。也可以用 S3、Azure Blob、GCS 自托管 state，state 用对称密钥加密，并集成 KMS、Vault、Key Vault 做 secrets 管理。
AWS CDK 直接复用 CloudFormation 的 stack 状态，state 由 AWS 托管在 CloudFormation 服务中，无需用户管理。这是 CDK 的优势之一：免去 state 烦恼。但代价是只能在 AWS 范围内使用。无论选哪个工具，最佳实践都是：远端 + 版本控制 + 加密 + 跨区复制 + 定期备份演练；apply 前必须取得分布式锁；不在 Git 里 commit 任何 state 文件。
多云支持与 Provider 数量
Terraform Registry 仍是当前最大的 IaC 生态枢纽，截至 2026 年初官方与社区 Provider 已超过三千个，覆盖所有主流公有云、私有云、监控平台、SaaS、CDN、CI 系统。中文资料里 AWS、Azure、GCP、阿里云、腾讯云、华为云、火山引擎都能直接找到 Provider。OpenTofu 完全复用这些 Provider。
Pulumi 的 Provider 数量增长很快，许多 Provider 是基于 Terraform Provider 自动生成的（pulumi-tf-provider-bridge）。这意味着在 AWS、Azure、阿里云这类大型云上，Pulumi 与 Terraform 的能力非常接近。少数小众 Provider 可能晚一两个月出现在 Pulumi 端。
AWS CDK 仅支持 AWS。CDK for Terraform（CDKTF）借助 Terraform 引擎间接支持多云，让你可以用 TypeScript/Python 写代码、底层走 Terraform Provider，是 AWS 之外用户的折中选择。多云项目首选 Terraform/OpenTofu，单云 AWS 项目可选 CDK 或 Pulumi。
模块化与抽象
Terraform/OpenTofu 通过 Module 实现复用。Module 是一组资源、变量、输出的封装，可以发布到 Terraform Registry、Git 仓库、S3 等位置，团队按版本号引用。社区提供大量公共 Module，例如 terraform-aws-modules、terraform-aliyun-modules，覆盖 VPC、EKS、RDS 等常见场景。Module 的接口由变量与输出定义，足够稳定但不够灵活。
Pulumi 把同样的概念称为 Component Resource。它本质是一个继承自 ComponentResource 的类，把内部资源封装成抽象单元。由于宿主语言完整，Component 可以暴露方法、属性、事件，像普通对象一样组合。CDK 用 Construct 实现类似抽象，AWS 提供了大量高质量 L2/L3 Construct，比如 aws-ecs-patterns、aws-cdk-lib，能一行代码起一个完整 Fargate 服务。
如果你的团队需要发布"一键部署模板"给业务线使用，Terraform Module 的成熟度更高，文档与版本管理基础设施齐备。如果你做平台工程，希望把基础设施作为内部 SDK 暴露给多个产品线消费，Pulumi Component 与 CDK Construct 在抽象能力上更强大。
学习曲线与人才市场
Terraform/OpenTofu 入门曲线相对平缓。HCL 语法只有十几个关键字，run 模型就是 init、plan、apply、destroy 四步。新人一周能写出像样的小项目，第二周开始接触 Module 与 Workspace。难点出现在大规模管理：状态拆分、跨账户权限、动态生成资源等都需要经验。
Pulumi/CDK 对会写代码的人门槛极低——熟悉 TypeScript 或 Python 就能直接读懂示例。但写出可维护的 IaC 代码反而难度更高，因为编程语言无所不能，新人很容易把基础设施代码写成一堆条件分支与外部调用。团队需要建立 lint 规则、Pre-commit 钩子、Code Review 模板。
从招聘市场看，Terraform 工程师人数远多于 Pulumi 与 CDK 工程师，国内 JD 也以 Terraform 为主。学习资源、培训课程、HashiCorp Certified: Terraform Associate 认证等基础设施都更成熟。Pulumi/CDK 对纯应用开发者更友好，对纯运维背景的团队反而需要补编程功底。OpenTofu 因为与 Terraform 兼容，人才直接复用。
CI/CD 与策略即代码
IaC 真正发挥价值是在 CI/CD 与 Code Review 流水线中。常见做法：在 PR 阶段跑 plan/preview，把变更摘要贴到 PR 评论；通过审查后合并到 main 分支，CI 自动 apply。Atlantis 是 Terraform 的开源 CI 框架，Spacelift、Env0、Scalr 是商业 SaaS，Pulumi Deployments 提供 Pulumi 原生流水线，CDK 借助 GitHub Actions 或 CodePipeline 流水线。
策略即代码（Policy as Code）是大型组织避免误用 IaC 的关键。HashiCorp 提供 Sentinel（商业版）与开源 OPA 集成；Pulumi 提供 CrossGuard，可以用 TypeScript/Python 写策略；CDK 通过 cdk-nag 提供安全检查。常见策略例子：所有 S3 bucket 必须开启加密、生产环境不允许公网 IP、所有数据库实例必须有备份。这些规则在 PR 阶段执行，能将合规问题扼杀在合并前。
漂移检测同样重要。把 plan 任务放进每日定时流水线，对比 state 与云上实际，发现外部直接修改的资源即时告警。商业平台 Terraform Cloud、Spacelift、Pulumi Cloud 都内置漂移仪表板。检测到漂移后第一步是评估是否合规变更，再决定 reset 或更新代码。
2026 年选型建议与组合策略
企业基础设施团队、追求最大社区生态与最丰富 Module 库：选 Terraform 或 OpenTofu。出于许可合规担忧，OpenTofu 是更稳妥的长期选择，国内云厂商已积极支持。如果你需要 Terraform Cloud 的商业能力，可以并行使用。
全栈与产品工程团队、希望用熟悉的编程语言写基础设施、需要细粒度抽象与单元测试：选 Pulumi 或 CDK。仅 AWS 项目用 CDK 最方便，多云项目用 Pulumi 或 CDKTF。注意通过 CrossGuard、cdk-nag、Code Review 模板抑制命令式语言的滥用风险。
混合策略也越来越常见：用 Terraform/OpenTofu 管 VPC、IAM、跨账户共享资源，用 Pulumi/CDK 管业务线的 Lambda、ECS Service、数据库实例。两者通过 remote state 数据源互相引用，团队各取所长。无论选哪一个，都不要忽视基本功：state 远端后端、变更评审、漂移监控、策略检查、GitOps 流水线、敏感数据加密。最后提醒：IaC 不是终点，而是平台工程的起点。再优秀的工具也代替不了清晰的资源命名规范、合理的环境拆分、完善的灾备演练。
常见问题
OpenTofu 现在到底成熟到什么程度？
OpenTofu 已发布 1.6、1.7、1.8、1.9 多个版本，加入了 Provider 端到端加密、状态加密、早期变量评估、动态 Provider 等独立功能，迭代节奏不亚于官方 Terraform。State 文件、Provider、HCL 与 Terraform 完全兼容，命令名 tofu。GitLab、Spacelift、阿里云、腾讯云已默认集成 OpenTofu。许多团队已把 CI/CD 中的 terraform 命令直接换成 tofu，零代码变更。出于 BSL 许可证合规担忧的企业基本都倾向 OpenTofu。
CDK 与 Terraform 怎么选？
AWS CDK 用 TypeScript/Python 等真实编程语言生成 CloudFormation 模板，仅适用 AWS（CDK for Terraform 借助 Terraform 后端可支持多云）。Terraform 是多云通用，HCL 简洁但受限。如果你 100% 在 AWS 上、团队偏开发者背景，CDK 在抽象与 IDE 体验上更强；如果你跨云或希望最大社区生态，Terraform/OpenTofu 仍是更稳妥的选择。CDKTF 也是不错折中，享受编程语言又能跑在 Terraform 引擎上。
Pulumi 用编程语言写 IaC 会不会失控？
是真实风险。命令式语言能写出难以审查的循环、条件、外部 HTTP 调用，违背 IaC 应当可重放可审计的初衷。最佳实践是限制单文件长度，用纯函数生成资源，避免在代码里做副作用，PR 阶段强制走 Code Review，并搭配 Pulumi CrossGuard 或 OPA Gatekeeper 做策略检查。这样既享受类型与 IDE 智能提示，又保留 IaC 的安全边界。
state 文件应该放在哪里？
state 是 IaC 的核心资产，必须存在带版本控制与并发锁的远端后端：AWS S3 + DynamoDB、Azure Blob、GCS、阿里云 OSS + TableStore、Pulumi Cloud、Terraform Cloud、Spacelift、scalr。务必启用 Versioning 与跨区域复制，开启加密，并定期演练恢复流程。绝对不要把 state 文件 commit 进 Git。OpenTofu 1.7 起支持原生 State 加密，建议立即开启。
中国云厂商对 IaC 工具的支持如何？
阿里云、腾讯云、华为云都有官方 Terraform Provider，覆盖主流资源（ECS、VPC、SLB、RDS、Kubernetes 等），活跃度也较高，Terraform Registry 上可直接搜到。OpenTofu 因兼容 Terraform Provider，所有这些 Provider 都能复用。Pulumi 通过 tf-provider-bridge 自动生成阿里云、腾讯云的 Pulumi Provider，覆盖度接近原生。AWS CDK 不支持中国云。综合看，国内团队最稳妥的是 Terraform 或 OpenTofu。