WebAssembly Component Model 深度实战：从 Canonical ABI 到 Polyglot 组件沙箱

WebAssembly 从 1.0 到 2.0 走过了标准化的快速通道，但真正让它在服务端生态中从"可嵌入的执行沙箱"蜕变为"可组合的多语言运行时"的，是 Component Model 这个仍处于_preview_阶段的提案。本文深入剖析 Component Model 的核心设计、Canonical ABI 的精密机制、WIT 接口定义语言的实战用法，以及在生产环境中部署 polyglot 组件的完整链路。

1. 为什么需要一个组件模型

WASI Preview 1 暴露了一个根本性缺陷：模块之间的交互完全依赖导入/导出函数的扁平列表，没有类型系统，没有命名空间，没有接口抽象。这意味着当你想把一个 Rust 写的图像压缩模块和一个 Go 写的元数据解析模块组合在一起时，你需要手动管理线性内存的分配与释放、字符串的编码转换、以及复杂的跨模块调用约定。

更致命的问题是语言运行时隔离。Preview 1 假设每个模块都有独立的实例，但当一个模块内部同时需要 GC 堆（比如 Go 的 goroutine 调度栈）和线性内存管理时，"WASM 模块"作为组合单元开始显得力不从心。Component Model 的提出正是为了解决这些问题：

• 接口契约：通过 WIT（WASM Interface Types）定义跨语言的类型化接口，编译器自动生成 ABI 转换代码
• 组合性：组件可以嵌套包含其他组件，形成有向无环图（DAG），独立编译后离线链接
• 隔离保证：每个组件实例拥有独立的线性内存和 table，杜绝跨组件的越界访问
• VES 统一化：无论是浏览器、边缘节点还是嵌入式设备，组件的执行语义一致

2. 核心概念解析

2.1 Component vs Module

Component Model 引入了严格的分层抽象。一个 Component 是顶层的、可链接的、带类型化接口的单元，它由若干 Core Module（即传统的 WASM 模块）组合而成。理解这一层级的关键在于：Component 是"编译和链接时的概念"，而 Module 是"运行时的概念"。

一个典型的组件结构如下：

my-component.wasm
├── Interface: "image-processor"
│   ├── export optimize(input: list