Alchemy v2：把云资源、IAM、环境变量都写进一个 TypeScript 文件的 IaC
阅读时间: 大约 8 分钟
Alchemy v2：把云资源、IAM、环境变量都写进一个 TypeScript 文件的 IaC
基础设施即代码（IaC）这两年有一条清晰的路线：从 YAML（Terraform/CloudFormation）走向真正的编程语言——Pulumi 是先行者，SST 把它推到 Serverless 场景。Alchemy v2 是这个阵营里的新成员：所有云资源、IAM 权限、绑定的环境变量都在一个 alchemy.run.ts 里定义，类型自动推导。v2 最大的变化是把重型函数式库 Effect 从「必选」改成「可选」。本文基于其官网做分析。
一、它长什么样
Alchemy 的核心理念是「snap together cloud resources（把云资源拼起来）」，你声明组件，它负责接线。官网示例：
export default Alchemy.Stack("my-app", { providers: Cloudflare.providers() },
Effect.gen(function* () {
const api = yield* Api; // 后端：Cloudflare Worker
const web = yield* Cloudflare.Website.Vite("Web", {
env: { VITE_API_URL: api.url }, // 前端：Vite，自动注入 API 地址
});
return { web: web.url, api: api.url };
}));关键点：api.url 不是手填的字符串，而是后端组件输出的类型化值——前端环境变量在编译期就和后端资源绑定，拼错资源名、引用不存在的输出，TS 编译器直接报错。这就是 Koala 说的「把 IAM 策略和资源绑定做成编译期类型检查，消除一类部署事故」。
覆盖的 provider 相当全：Cloudflare、AWS、Hetzner、Fly、Railway、Neon、PlanetScale、Prisma、Docker、Stripe、GitHub、Axiom。
二、三个核心工作流
alchemy dev：本地一键起全栈——每个后端服务跑本地模拟器或代理真实服务，每个前端起 dev server 并自动配 HMR，不用自己拼十个终端；alchemy test：部署一个临时栈，让测试打真实基础设施（官网示例是真 R2、真 DynamoDB），跑完销毁；CI 里测试还能复用 PR 预览栈，避免重复部署；alchemy plan / deploy / destroy：plan 干跑看变更，deploy 把基础设施对齐到期望状态，destroy 带防护防止误删数据。
官网称从 PR 打开 → 部署 → 测试 → 合并的整套 CI 体验，约 25 秒跑完全程（首页 hero 里 deployed in 2.2s 是单个部署的时间）。还默认接好日志、spans、metrics 可观测。
三、v2 的关键修正：Effect 不再必选
这是 v2 最重要的产品决策，值得单独讲。v1 的 Alchemy 重度依赖 Effect这个函数式 TypeScript 库——上面示例里满眼的 Effect.gen、yield* 就是它的风格。问题是：Effect 的学习曲线极陡，不懂函数式的团队看 v1 代码近乎劝退。
v2 把 Effect 改成可选：普通团队可以用更常规的 TS 写法，只在需要 Effect 那套错误处理/依赖注入能力时才引入。Koala 的点评准确：这是「务实的修正」——先把受众从「Effect 爱好者」扩大到「普通 TS 团队」，再谈 adoption。
四、必须自己承担的 tradeoff
不是银弹：样板代码与学习曲线。用 TS 写 IaC 比 YAML 灵活，但前置样板（Stack、providers、Layer 绑定）比 Terraform 的 HCL 啰嗦；Koala 明确指出前期样板多、学习曲线比 Terraform 陡。Effect 即使可选，示例代码仍默认函数式风格，团队要不要学是个决策。
还在 beta，生产需谨慎。官网没有宣称 GA，Koala 也提醒「目前还在 beta」。IaC 直接管你的云资源，beta 阶段的 provider 覆盖度、drift 处理、状态管理成熟度都要自己压测。
「类型安全」覆盖的是接线，不是云 API 本身。编译期能抓住「环境变量引用错资源」「IAM 绑定写错」这类错，但抓不住「R2 配额不够」「AWS 侧账号限额」这类运行期问题——别把类型安全当成部署零风险。
25 秒是官方演示口径。从 PR 到测试完的时间取决于你栈的大小、provider 数量、CI 冷启动，不能外推到大型微服务。
厂商覆盖与 SST/Pulumi 重叠：它不是空白市场，要在 SST、Pulumi、Terraform CDK 之间选，迁移成本与生态成熟度都要比。
五、适用与不适用场景
适合： 全 TS 技术栈、想用同一种语言管前后端与云资源的团队；主要跑在 Cloudflare/Fly/Railway 这类现代平台、要 PR 预览栈 + 真基础设施测试的产品；愿意接受类型化 IaC、想消灭「环境变量拼错」这类事故的人。
不适合： 已经在 Terraform 生态里有大量模块、不想重写的团队；不熟 TypeScript、团队更熟 HCL/YAML 的人；需要 GA 级稳定、多云复杂编排的生产基础设施。
六、客观分析：优势与意义
优势： TypeScript 原生 + 资源接线编译期类型检查，直击 IaC 最常见的「环境变量/IAM 拼错」事故；dev/test/deploy 三工作流一体，PR 临时栈 + 真基础设施测试是现代 CI 的好范式；v2 把 Effect 改可选，明显降低门槛；provider 覆盖现代 Serverless 平台。
局限： beta 未 GA；样板多、曲线陡；类型安全不覆盖云侧运行期问题；与 SST/Pulumi 竞争激烈；25 秒是演示口径。
Alchemy 代表的趋势是：IaC 正在从「声明式配置」演变成「可编程、类型安全、和应用同语言」的工程。当整个团队已经在写 TypeScript，让云资源也享受 TS 的类型推导与重构工具，是顺理成章的下一步。v2 松开 Effect 这个决定，说明它终于想清楚了：IaC 框架的第一要务不是函数式优雅，而是让最多团队敢用。