WebAssembly Component Model：不同语言写的模块如何拼在一起？

WebAssembly 最初给人的印象是“把 Rust、C 或 C++ 编译成一个 .wasm 文件，然后放进浏览器运行”。但当系统变大，单个模块很快就会遇到边界问题：不同语言之间怎么传字符串和列表？模块怎样访问文件和网络？多个模块如何安全地组合？

WebAssembly Component Model 正在把 WebAssembly 从“可执行文件格式”推进成“可组合的组件接口”。它关心的不只是代码能不能跑，还关心不同语言、不同运行时和不同权限之间如何互相协作。

先给结论：Component 是带接口的 Wasm 单元

传统 Wasm module 暴露的是比较底层的函数和线性内存。宿主和模块之间要自己约定指针、字符串编码、内存分配和错误处理。

Component 则试图把这些约定提升为接口层。组件可以声明自己提供什么函数、接受什么数据、返回什么结果，以及需要哪些宿主能力。WASI 0.2 就是建立在 WebAssembly Component Model 之上的系统接口规范。WASI 0.2 说明

可以把 module 理解成“能运行的一段机器码”，把 component 理解成“带明确插口的可组合软件包”。

为什么需要 WIT

Component Model 生态里常见的接口描述语言是 WIT（Wasm Interface Types）。它不是某一种编程语言，而是一份跨语言的契约：定义类型、函数、错误和资源如何在组件边界传递。

一个概念性的接口可能长这样：

package foundit:search@1.0.0;

interface search {
  record query {
    text: string,
    limit: u32,
  }

  search: func(input: query) -> result<list<string>, string>;
}

真正的语言绑定和工具链会把这份接口生成成 Rust、Go、Python 或 JavaScript 可以使用的类型。这样，调用方不必知道另一个组件内部如何分配内存，也不必手写一套语言相关的 FFI 胶水。

组件如何组合

一个真实系统可以由多个来源不同的组件组成：

组合并不意味着组件自动拥有所有权限。宿主运行时可以决定：给某个组件文件读权限，但不给网络权限；给另一个组件网络访问，但只允许访问指定域名。能力被显式传入，权限边界就比“所有代码共享一个进程”更容易审计。

WASI 不只是“浏览器之外的标准库”

WASI 常被简化成“Wasm 的文件系统接口”。这个理解太窄了。WASI 的方向是为 WebAssembly 组件提供一组模块化、可组合的系统能力，例如输入输出、文件、网络、随机数、时钟以及异步相关的接口。

它的重点不是复制某个操作系统的全部系统调用，而是把能力拆成可授予、可替换的接口。一个组件只需要声明“我需要读取配置文件”，宿主再决定给它真实文件、内存中的虚拟文件，还是拒绝访问。

它和容器有什么区别

两者都可以用来隔离代码，但抽象层不同：

Component Model 并不是容器的替代品。一个大型服务仍然可能运行在容器里，而其中的插件、规则引擎或用户代码则以 Wasm component 的形式加载。

真正的难点在生态成熟度

Component Model 解决了接口表达和组合方向，但工具链仍然在发展。实际项目需要确认：

• 目标语言是否有稳定的组件编译与绑定工具；
• 目标运行时是否支持需要的 WASI 版本；
• 异步、资源句柄和错误类型能否跨语言保持一致；
• 依赖的宿主能力是否在浏览器、边缘平台和服务端都存在。

如果项目只是把一段计算放进浏览器，普通 Wasm 可能已经足够；如果项目需要动态加载插件、隔离不可信代码，或让多个语言生态共享一套接口，Component Model 才更有价值。

一条实用的判断标准

当你发现系统里出现大量“每种语言一套 FFI”“插件必须绑定某个宿主语言”“权限只能靠进程级隔离”时，可以认真评估 Component Model。

一句话总结：WebAssembly module 解决“代码怎么运行”，Component Model 进一步解决“代码怎样带着接口和权限组合”。

来源

• WebAssembly：WASI 与规范
• WASI 0.2.12 Overview