Wing vs Pulumi：同一款云应用，7 行 Wing 对比 98 行 Pulumi 的完整差异解析

• 编程语言
• 编译器
• 云原生
• 语言运行时

本文基于 Wing 官方 FAQ 中的《Pulumi vs. Wing》对比文档展开，围绕一个具体场景——"用云函数把文本文件上传到 Bucket"——逐行对比 Wing 与 Pulumi 两种技术路线的代码量、IAM/网络等云机制的处理方式，并结合 Wing 仓库中的 SDK 源码，解释 Wing 是如何"从意图自动生成基础设施"的。读完本文，你能清晰判断两者的适用边界：何时用 Pulumi 手动掌控基础设施，何时用 Wing 让编译器替你做这些事。

核心定位差异：语言 vs 工具

首先要明确两者不是同类产品：

• Wing是一门通用编程语言，目标是开发完整的云应用——基础设施和应用代码都写在这门语言里，由编译器统一编译；
• Pulumi是一个 Infrastructure as Code（IAC）工具，只负责应用中的基础设施部分。基础设施与应用代码之间，还需要你自己设计一套拼接方式（例如通过环境变量、命名约定把资源引用传给应用代码）。

这一点也体现在两者的扩展模型上：Pulumi 用 custom provider / dynamic provider 扩展；Wing 则用自定义资源（custom resources）扩展，且基础设施与应用代码共享同一类型系统。

四大主要差异

对比文档归纳的四条核心差异如下：

1. 云可移植性（cloud-portable）。Wing 代码一次编写、可编译到不同云平台；Pulumi 虽然支持多家云，但每一家云都需要编写各自的具体代码（AWS 用@pulumi/aws，GCP 用@pulumi/gcp……）。
2. 基础设施从意图自动生成。因为 Wing 编译器同时看得见基础设施代码和应用代码（inflight 闭包），它能自动推导并生成大量在 Pulumi 里必须手工定义的内容，典型如IAM 策略和网络拓扑。
3. 未来可编译到 JavaScript 和 Pulumi。对比文档明确指出这是路线图（roadmap）上的能力，届时可以通过 Wing 的 compiler plugins 直接定制生成的 Pulumi 输出。
4. 本地模拟与可视化。Wing 内置本地仿真器（simulator），支持即时热重载，无需上云即可开发调试；使用 Pulumi 时通常必须部署到云上才能与应用交互，耗时数分钟。

Wing 的本地仿真能力在文档 docs/docs/02-concepts/05-simulator.md 中有完整介绍，本地开发流程见 docs/docs/01-start-here/04-run-locally.md。

代码示例：同一个应用，两种写法

对比文档选取的示例应用很简单：一个云函数（Function）把文本文件上传到桶（Bucket）。文档原文通过仓库中的 CodeComparison 组件 自动加载两侧代码，示例源码实际存放在 docs/docs/src/examples/function-upload-to-bucket/ 目录下，可直接查看原始文件。

Wing 侧：7 行代码

hello.w 全文如下：

bring cloud; let bucket = new cloud.Bucket(); new cloud.Function(inflight () => { bucket.put("hello.txt", "world!"); });

注意第 5~7 行：bucket被捕获进inflight闭包后，bucket.put(...)这行应用代码就是"意图"本身——Wing 编译器看到函数需要向 Bucket 写对象，会自动为该函数生成所需的 IAM 权限、代码打包与部署配置，开发者完全不接触角色、策略文档这类细节。

Pulumi 侧：3 个文件、约 98 行

Pulumi 版本需要3 个文件协作：

1. main.ts（63 行）——基础设施定义。这里可以看到与 Wing 自动生成形成鲜明对照的手工部分：

• 手写 IAM 角色的信任策略（sts:AssumeRole给lambda.amazonaws.com，对应aws.iam.Role）；
• 手写角色策略（aws.iam.RolePolicy）：手工声明 CloudWatch Logs 的三条权限（logs:CreateLogGroup/logs:CreateLogStream/logs:PutLogEvents）和指向${bucket.arn}/*的s3:PutObject；
• 手工创建aws.lambda.Function，并用环境变量BUCKET_NAME把资源引用"接线"到应用代码。

其中s3:PutObject这条策略正是 Wing 侧由bucket.put()一行代码隐式推导出来的等价物。

2. index.js（28 行）——Lambda 运行时代码，通过aws-sdk的S3.putObject完成上传，并从process.env.BUCKET_NAME读取桶名。

3. pulumi.yaml（8 行）——栈配置，声明aws:region（默认us-west-2）。

name: s3-lambda-pulumi runtime: nodejs description: A simple example that uploads a file to an S3 bucket using a Lambda function template: config: aws:region: description: The AWS region to deploy into default: us-west-2

差异对照表（文档原文完整保留）

文档同时注明：表中部分差异（如网络拓扑）在这个小例子里体现不出来，属于"放不进这么小的应用、但依然重要"的能力。

源码佐证：Wing 的 IAM 策略到底是怎么"自动生成"的

"Wing 从意图自动生成 IAM 策略"不是宣传语，仓库中有清晰的实现路径。以 AWS 目标为例，packages/@winglang/sdk/src/target-tf-aws/function.ts 中，SDK 在创建 Lambda 时会自动创建三样东西：

1. IamRole——信任策略硬编码为允许lambda.amazonaws.com执行sts:AssumeRole；
2. IamRolePolicy——内容由policyStatements动态产生。这些 statement 正是在 inflight 闭包中bind/引用资源（如bucket.put()）时由编译器收集进来的；若没有任何 statement，会注入一条none:null的 no-op 语句保证策略合法；
3. IamRolePolicyAttachment——自动附加 AWS 托管策略AWSLambdaBasicExecutionRole，等价于 Pulumi 示例里手写的三条logs:*权限。

也就是说，Pulumimain.ts中 40 多行的Role+RolePolicy样板，在 Wing 的 AWS 目标里全部由 SDK 代劳。至于s3:PutObject这条具体权限，可以从源码结构看到它由 packages/@winglang/sdk/src/shared-aws/permissions.ts 统一维护（其中s3:PutObject*、s3:Abort*等动作按资源使用场景聚合）。

跨云可移植性也有对应目录结构佐证：SDK 下同时存在target-tf-aws、target-tf-gcp、target-tf-azure三个目标实现（如 target-tf-aws/function.ts 与target-tf-gcp/function.ts均为同名构造物的平台实现），共用cloud/目录下的平台无关抽象（如 cloud/function.ts）与shared-aws/中的公共实现——这与对照表中"同一份代码编译到不同云"的说法一致。

适用边界与前提说明

基于以上证据，可以这样把握两者边界：

• 需要细粒度控制云厂商 API、已有 HCL/YAML 基础设施资产、或希望直接操作 provider 层：Pulumi 这类 IAC 工具更贴合；
• 希望基础设施与应用代码同源、同类型系统、跨云复用，且依赖本地仿真器快速迭代和免 mock 测试：Wing 的定位即为此设计；
• 需要注意的前提：Wing 编译到 Pulumi 的能力在对比文档中被表述为路线图（roadmap）上的未来工作，而非当前可用功能；当前版本的供应引擎为 JavaScript + Terraform / AWS-CDK。相关计划可参考仓库内的 roadmap 文档。

如果你希望继续深入 Wing 与 Terraform、AWS CDK、CDKTF 的同类对比，仓库中还有 041-terraform-vs-wing.md、043-awscdk-vs-wing.md、044-cdktf-vs-wing.md，它们与本篇使用同一个示例应用，可横向串联阅读。

• 编程语言
• 编译器
• 云原生
• 语言运行时