通往 WASM Component Model 1.0 之路：深度解读

背景

WebAssembly System Interface (WASI) 的 Preview 3 (P3) 版本即将发布，这将为核心 WebAssembly 系统接口及 Component Model（组件模型）带来原生的异步支持。然而，WASI P3 只是当前的重要节点，整个生态更宏大的目标是实现 Component Model 1.0 的稳定发布。

在二月份的 Bytecode Alliance Plumbers Summit 上，Luke Wagner 和 Alex Crichton 预览了通往稳定 1.0 版本的具体路径。随后，Luke Wagner 在 2026 年 3 月于巴塞罗那举行的 Wasm I/O 大会上进一步阐述了这一愿景。本文旨在梳理 Component Model 的发展现状、技术架构及其迈向 1.0 版本的关键工作领域。

核心内容

Component Model 与 WASI 的关系回顾

在深入未来之前，有必要厘清 Component Model 与 WASI 的定义及其相互关系：

• Component Model（组件模型）：这是建立在核心 WebAssembly 之上的规范层，定义了 Wasm 二进制文件如何打包、链接和通信。它规定了类型系统、二进制格式、接口定义语言（IDL），以及跨组件隔离边界传递类型化值的调用约定。
• WASI（WebAssembly System Interface）：这是一套标准化的 API 集合，用于以可移植且具备能力安全（capability-secure）的方式访问系统资源（如文件、套接字、时钟、随机数等）。

WASI 接口通过 Component Model 进行消费，二者共同构成了 Wasm 生态系统中可组合、可移植的基础。值得注意的是，Component Model 1.0 和 WASI 1.0 是相关但独立的里程碑：WASI 1.0 将依赖于 Component Model 先达到 1.0 版本。

Luke Wagner 在 Plumbers Summit 上将二者的关系比作微内核架构：

• Component Model 类似于始终存在的微内核，提供在任何主机上运行的基础原语。
• WASI 则像运行在微内核之上的操作系统服务（如网络、存储、图形），作为进程存在，且并非所有设备都具备。例如，浏览器对 I/O API 有严格限制，WASI 接口通过 polyfill 在浏览器中运行；但 Component Model 本身仅计算，不包含 I/O，因此可以原生实现于浏览器中，与核心 WebAssembly 并存。

尽管二进制格式和 WASI API 仍在演进，平台提供者和嵌入者已能提供强大的向后兼容性保证。P1 模块和 P2 组件依然有效。团队通过语义版本控制、并行实现以及 Wasm-to-Wasm 适配器维持了自 P1 以来的稳定性。正如 Luke 所言：“我们现在就可以开始使用这些技术。”

迈向 1.0 的五大工作领域

Luke Wagner 将通往 1.0 的路径划分为五个关键工作领域，其中前两个领域在原文中得到了详细阐述：

1. ABI（应用二进制接口）改进

当前的 Component Model ABI 依赖于一个名为 cabi_realloc 的函数约定，所有组件都必须导出该函数。当被调用方返回如字符串列表等值时，主机需调用调用方的 cabi_realloc 为每个元素分配内存，复制数据后再返回给调用者。这种方式存在诸多摩擦：

• 随时间推移导致的堆碎片化。
• 难以优雅地处理大型分配失败。
• 列表中每个值都需要一次主机到访客（host-to-guest）的调用。
• 难以使用自定义内存分配器。

改进方案：惰性 ABI（Lazy ABI） 计划中的变更将反转控制流。被调用方不再立即分配内存，而是返回惰性值句柄（opaque i32 索引）。当调用方准备将值放入内存时，会调用一个静态内置函数并传入目标地址。由于编译器静态知晓这些内置函数，它们可以被内联，如同指令一般。

惰性 ABI 的优势：

• 解决现有摩擦。
• 支持零拷贝转发（zero-copy forwarding）。
• 支持丢弃未使用的值。
• 将复杂的字符串转码逻辑从引擎移至访客代码中清理。

过渡策略：

• 非破坏性过渡：惰性 ABI 将作为新的可选功能在 0.3.x 小版本中发布。
• 生产工具链在准备就绪时采用。
• 1.0 发布时，若采用率完成，惰性 ABI 将成为默认选项，旧选项移除。
• 提供适配器工具将惰性组件转换为旧式组件。

附带改进：

• 多值返回（Multivalue returns）：在 C ABI 层面使用 Wasm 多值特性作为返回类型。
• 错误上下文：每个结果的错误情况中均包含错误上下文值，以便主机附加回溯和调试信息。

依赖与挑战：

• LLVM 目前尚不支持 C ABI 层面的多值特性。虽然精确的 ABI 提案已存在，但将其合并上游可能是此项工作中耗时最长的部分。
• GC ABI 选项：计划中的独立 GC ABI 允许组件通过 Wasm GC 分配的内存传递值，而非线性内存，从而避免基于 GC 的语言通过线性内存进行复制。Nick Fitzgerald 已在 Component Model issue 525 中提出预提案。

性能目标：同步调用零开销 当前实现通过主机调用在组件边界间管理异步任务基础设施，这带来了约 3.5 倍的开销（即使是在纯同步调用路径上，据 Nick Fitzgerald 在 Plumbers Summit 上的测量）。部分问题已在规范层面解决（P3 开发期间移除了递归检查）。剩余工作计划在 WASI P3 发布后进行，通过重构任务状态，使同步适配器在栈上分配轻量级任务，让 Cranelift（Wasmtime 的优化代码生成后端）等编译器能将其大部分优化掉，从而恢复组件模型异步支持添加之前的同步适配器性能曲线。

2. 浏览器路径

Component Model 要正式达到 1.0，必须在至少两个浏览器引擎中获得原生实现支持。目前的基础工作正在进行中：

• 现有方案：jco 的 transpile 命令可以将任何组件转换为等效的核心 Wasm 和 JavaScript 胶水代码，使其能在任何浏览器中运行，无需原生支持。
• 原生支持的重要性：
  • 性能：Mozilla 的 Ryan Hunt 的实验显示，在 DOM 变更频繁的 Wasm VDOM 协调循环中，直接通过 Wasm 到浏览器 API 调用（绕过 JavaScript 胶水层）可获得接近 2 倍的速度提升。
  • 覆盖面：浏览器中的原生 Component Model 支持将强烈激励上游语言、包和框架的 Wasm 支持，从而在所有 Wasm 运行平台上改善开发者体验。

获取支持的策略： 借鉴 WebAssembly 自身的历史。当 asm.js 发布时，它包含一个无操作的 "use asm" 字符串，浏览器引擎可通过功能使用遥测数据检测该字符串，从而构建数据驱动的优化案例，最终促成 WebAssembly 的诞生。 jco 正在采取相同策略：其生成的 JavaScript 胶水代码现在会发出 "use components" 标识符（在 jco 1.16.8 中从 "use jco" 重命名）。随着 jco 转换的组件积累真实世界的使用量，这些数据将成为原生实现的有力证据。

业界反应：

• Mozilla：团队在最近一次线下的 WebAssembly CG 会议上展示了性能结果，Ryan Hunt 也在近期博客中讨论了 Mozilla 的 Component Model 工作。
• Chrome (V8)：V8 团队已开启一个 Issue 以评估 Component Model 的实现。

(注：原文在此处截断，未提及剩余三个工作领域，故解读仅基于已提供的文本内容。)

关键要点

• WASI P3 与 Component Model 1.0 的关系：WASI P3 带来原生异步支持，但 WASI 1.0 的达成依赖于 Component Model 先达到 1.0 版本。
• 架构类比：Component Model