WebAssembly 组件模型

WebAssembly 组件模型（WebAssembly Component Model，常简称组件模型或 CM）是一套构建在核心 WebAssembly（Core Wasm）之上的模块化与互操作设计。它把程序的输入、输出和依赖表示为带类型的接口，使不同语言编写、采用不同工具链生成的模块能够通过共同约定连接。它不是核心指令集的一种新语言，也不是特定运行时或操作系统接口；其设计同时面向服务器、边缘设备、插件系统等非浏览器环境。WebAssembly 工作组在 2026 年章程中把它描述为一种分层于核心规范之上的可移植、轻量、跨语言、可组合模块，并说明它本身不赋予 Web 平台新的能力。W3C WebAssembly 工作组章程

核心 WebAssembly 模块是低层执行与链接单元，定义函数、表、线性内存、全局变量等，并通过导入和导出与宿主或其他模块连接。这个模型适合编译器生成紧凑的可执行代码，但对跨语言接口的高层数据类型、包级依赖和模块组合没有统一的描述方式：字符串、列表、记录、资源等常要由语言绑定或应用自行约定如何编码及传递。组件模型在这一层外增加组件类型、组件实例和组件级导入、导出等概念；一个组件可包含核心模块，也可包含其他组件。它仍使用核心 Wasm 执行组件内部的代码，而由外层结构描述如何实例化、连线并公开功能。组件模型规范仓库；组件模型说明文档

因此，“组件”并不意味着编程语言运行时、依赖管理器或完整操作系统容器。组件边界可以呈现有类型的服务契约，也可以承载资源句柄和受控的功能导入；宿主仍需决定能否访问文件、网络、时钟等外部能力。组件之间只可按其声明的接口交互，并不代表自动获得这些能力，也不意味着它们已经由任意浏览器或任意 Wasm 引擎支持。组件二进制采用独立的组件格式，可将一组核心模块及其连线封装起来；工具也能从带有相应 WIT 元数据的核心模块生成组件。模型的目标是让组合结构进入格式与类型系统，而非要求开发者从单体程序中拆出很多独立进程。组件模型规范与格式资料；wasm-tools 组件命令说明

WIT（Wasm Interface Type）是描述组件接口的 IDL。它以较高层的类型表达函数参数和结果，也可定义记录、枚举、变体、列表、结果类型以及资源句柄等。WIT 文件将接口与 world 组织为可共享的包；包名可含命名空间、包名和可选版本，便于在不同依赖间引用相同的接口定义。WIT 用于生成来宾语言绑定和宿主端绑定，也可作为平台共同定义 API 的载体；它只声明边界上可见的类型与功能，不描述接口内部的实现语言。WIT 格式说明

interface 表达一组相关类型与操作。world 则描述一个组件整体面向外界的契约，即它需要哪些导入、向外提供哪些导出；导入可以是函数、接口或其他外部类型，导出也可以采用这些形式。一个 world 常对应一个程序使用场景，例如命令行程序、HTTP 服务，或一个嵌入宿主的插件。生成绑定时，工具通常以所选 world 为单位，使来宾实现满足其导出要求，并使宿主提供其导入。world 的契约可进一步引入其他 WIT 包中的接口，因此依赖不仅是未解释的符号名，也能带上类型信息和版本语义。WIT world 说明

用一个简化例子来说，图像处理组件可以导入文件读取接口，导出接受图像字节并返回缩放结果的函数。WIT 让“文件句柄”“字节列表”“错误结果”的形状成为明确的接口定义；宿主可依据 world 提供文件能力，另一个组件则可实现图像运算。实际部署时，接口版本、运行时实现和宿主授权仍需相互匹配。组件模型的类型边界有助于描述数据和依赖，但不替应用决定信任策略、权限范围或生命周期管理。

WIT 中的字符串、列表、记录等抽象值，不能直接作为核心 Wasm 函数的调用值传递。核心层使用低阶数值、表和线性内存；因此组件模型定义了 Canonical ABI（规范 ABI），规定组件级函数如何转换为核心函数签名，以及值如何通过线性内存表示与复制。具体表示包括字符串编码、内存和分配器等选项。canonical lift 会将核心函数包装成组件级函数，canonical lower 则把组件级函数包装成可由核心 Wasm 调用的核心函数。借助这一层，语言绑定可以把 WIT 类型映射为各自语言的习惯类型，同时遵循同一边界约定。Canonical ABI 说明

组件组合建立在导入、导出和实例化之上。外层组件可以导入组件、创建其实例、别名引用已有导出，再将某个实例的导出接到另一个实例的导入；也可以把部分接口继续向上暴露。规范中的组件类型系统检查这些连接是否兼容，避免只靠字符串名称把不相容签名错误地连在一起。一个语言编译器产生的核心模块可先封装成组件，再与其他组件连接；工具可生成语言绑定、适配格式差异，并把组成关系编码进二进制文件。由此产生的是可重新组合、带有接口边界的构件，而非一个自动提供所有能力的单一包。组件模型说明文档；组件二进制与文本格式

Canonical ABI 也不是任意语言之间的“零成本调用”保证。复杂数据可能需要内存分配、编码、拷贝或转换，实际成本取决于数据类型、调用频率、实现与编译器。组件接口更重要的价值是让数据形状、调用方式和资源所有权等规则能够被工具检查并跨语言复用。资源类型可表达由组件创建、借用、传递或释放的外部对象句柄；它们提供了句柄式接口的类型约束，但不会替应用解决所有资源生命周期问题。组件模型规范与 ABI 细节仍在演进，开发者应对照所用运行时、WIT 包和工具版本，而不要把某个原型的行为假定为所有平台的永久保证。Canonical ABI 设计说明；WIT 类型与资源定义

WASI（WebAssembly System Interface）是一组面向宿主服务的接口约定，例如命令行 I/O、文件系统、时钟、随机数、网络和 HTTP。它与组件模型有关联，但两者并非同一项目：WASI 的组件接口用 WIT 表达，并借助组件模型组织导入和导出；组件模型本身则是更底层、更通用的封装与组合机制。WASI 0.2 系列已基于组件模型形式发布，WASI 0.3.0 则于 2026 年 6 月 11 日发布并获 WASI 子组批准，改以组件模型的异步原语表达一系列接口。它让异步函数、future 与 stream 成为接口设计的一部分；此前一些轮询与开始／完成式调用被改写为 async 函数及 future、stream 组合。WASI 0.3.0 发布说明

WASI 0.3.1 于 2026 年 8 月 11 日发布，在 0.3.0 的基础上采用 WIT 的 map<K,V> 类型，以及 implements、external-id 注解。它们允许接口表达字典类型，也能处理同一接口的具名实例或外部标识；要兼容 0.3.1，运行时和工具链必须支持这些功能。后续点版本可以吸纳更多组件模型功能，但每个版本只选取其中一部分，并不等于整个组件模型规范已经定稿。WASI 0.3.1 发布说明；WASI 0.3 发布与支持说明

这一区分尤其重要。截至 2026 年 10 月 4 日，WebAssembly 官方提案追踪器仍将 Component Model 列在 Phase 1（提案阶段）；W3C 工作组章程则明确表示，正式的 W3C Component Model 规范交付取决于该提案达到 Phase 4。因而，已发布并可稳定采用的 WASI 版本，只表明其中获采纳的功能子集具有发布版本与实现实践，不表示完整组件模型已经走完标准化流程。组件模型仓库说明，当前工作正随 WASI Developer Preview 逐步开发；预览版所包含的组件模型功能会由生产者与消费者工具保持稳定，因此可用于浏览器之外的生产环境，以收集真实世界反馈。稳定可用、WASI 版本化和完整标准定稿是不同层次的状态。提案阶段追踪表；W3C 工作组章程；组件模型里程碑说明

实现支持必须按具体版本与功能核对。WASI 项目记录称，Wasmtime 46 起默认启用最终发布版 WASI 0.3.0 及其组件异步功能；Wasmtime 46 是首个实现最终版 WASI 0.3.0 的版本。这个默认支持不意味着 WASI 0.3.1 新增的 map<K,V>、implements、external-id 已默认启用；应针对目标运行时逐项核实这些功能是否受支持，并按实现要求启用。更早版本提供过候选快照支持，但需启用特定组件模型功能门。WASI 0.3.1 的文档列出除 0.3.0 的 async、future、stream 外，还需 map<K,V>、implements 和 external-id 等相关能力；功能门和版本不一致可能使生成的组件与宿主无法正确实例化。团队应将运行时、绑定生成器与 WIT 依赖锁定在兼容版本，而非仅凭“支持组件模型”的概括判断。WASI 0.3 运行时与工具链支持；Wasmtime 组件模型功能稳定性说明

工具链承担不同工作，不能把它们都当作运行时。wasm-tools 可检查组件 WIT、验证和转换二进制、把核心模块封装成组件，或处理 WIT 包；这些功能本身不负责在宿主中执行组件。jco 可把组件转译为 JavaScript ES 模块，以 Node.js 或浏览器的核心 WebAssembly 支持和 JavaScript 代码承接高级组件功能；这是一种转译路径，不是浏览器原生普遍支持组件模型格式的证明。WIT-bindgen 可为 Rust、C、C++ 等语言生成绑定，但不负责宿主执行；componentize-py 则提供把 Python 应用目标化为组件的工具。Rust、C/C++、JavaScript 和 Python 方案的成熟度、目标接口版本和限制并不相同。wasm-tools 组件工具；jco 工具说明；wit-bindgen 支持范围；componentize-py

因此，评估一个组件能否投入生产，通常要分别检查：其 WIT world 与版本、所需 WASI 接口、组件二进制使用的组件模型功能、目标运行时是否实现这些功能，以及工具生成结果是否和宿主匹配。不同运行时的支持并不自动相互兼容；同一工具也可能同时支持不同版本的组件与 WASI 接口。浏览器环境尤其需要区分“以 JavaScript 转译方式运行”与“浏览器引擎原生接受并执行组件模型”，不能仅由核心 WebAssembly 在浏览器中广泛可用推断出后者已普及。这个分层架构为跨语言复用提供了共同格式与接口语言，但部署兼容性仍取决于具体功能集和版本组合。