Wasm Component Model 解决了什么接口复用问题

Wasm Component Model 解决的核心不是“把任意 Wasm 文件拼在一起”，而是把组件之间的调用约定提升为可描述、可检查、可组合的接口。传统 WebAssembly core module 可以导入和导出函数，但复杂数据通常要靠线性内存、指针和调用方约定来传递；一旦实现语言或内存布局变化，复用就容易被底层 ABI 绑住。

官方资料：https://component-model.bytecodealliance.org/

Component Model 用 WIT 描述接口和 world：接口负责复用类型与函数契约，world 负责声明一个组件提供什么、依赖什么；当一个组件的导出能够满足另一个组件的导入时，运行时或工具链就有了可检查的组合边界。

因此，标题中的“接口复用问题”可以具体理解为：同一份接口定义能否被不同语言实现、不同宿主提供，并在组合前明确检查输入输出，而不是每个调用方都重新猜测内存布局。

core module 为什么容易把复用绑在 ABI 上

core module 的导入导出边界主要围绕函数、数字类型和线性内存展开。传递一个整数通常没有困难，但传递字符串、列表、记录或错误结果时，调用双方还要约定指针指向哪里、长度如何解释、内存由谁分配，以及调用结束后谁负责清理。

这些约定当然可以做成 ABI，但它们往往隐藏在绑定生成器、运行时版本或某个语言的布局规则中。结果是：一个 Rust 组件能被某个宿主调用，不代表另一个语言可以直接复用；即使函数名字相同，复合数据的表示也可能不兼容。

// 下面是概念性的低层边界：调用方还要知道内存布局
export "process" (param i32 i32) (result i32)
// 第一个 i32 可能是地址，第二个 i32 可能是长度；具体含义不在函数签名中

这不是说 core module 没有价值，而是它更像组件内部的执行单元。若把它直接当成跨语言公共 API，调用方需要额外维护一套隐藏契约，这正是接口复用成本的来源。

WIT 怎样把类型和函数契约提到边界上

WIT（WebAssembly Interface Types）是 Component Model 使用的接口定义语言。它描述的是类型和函数，不直接描述实现行为；实现可以来自 Rust、Go、C、Python 等语言，但组件边界上的名称、参数和返回值先由同一份契约表达。

package demo:catalog;

// 接口只描述可复用的类型和函数，不绑定某一种实现语言
interface catalog {
    // record 让调用双方共享字段含义，而不是自行解释内存中的偏移
    record item {
        id: u64,
        title: string,
    }

    // result 明确区分成功值与可处理的业务错误
    get-item: func(id: u64) -> result;
}

这个例子里的 item、string 和 result 都是接口层语义。工具链可以依据 WIT 为不同语言生成绑定，调用方不必把 id、字符串地址和错误码重新拼成一套私有协议。

接口还可以复用另一个接口中已经定义的类型。例如多个业务接口都使用同一个用户记录时，可以通过 use 引用公共类型，减少“字段名称相同但含义稍有不同”的漂移。复用的重点不是复制一段代码，而是共享一份能被工具理解的契约。

world 怎样描述组件的输入和输出

接口回答“有哪些函数和类型”，world 则回答“这个组件对外提供什么、运行时需要提供什么”。它把多个导入和导出收拢成一个组件表面，因此宿主、组件和组合工具都能从同一份定义理解依赖方向。

interface logger {
    // 宿主提供日志能力，组件只依赖这个最小接口
    write: func(level: string, message: string);
}

world catalog-service {
    // 组件对外提供目录查询能力
    export catalog;

    // 组件运行时需要宿主提供日志能力
    import logger;
}

从这个 world 可以读出两件事：目录组件实现并导出 catalog，同时不能假设自己拥有任意系统能力，因为它只声明了对 logger 的依赖。宿主可以实现这个导入，也可以由另一个组件的同名导出来满足它。

它具体解决了哪些接口复用问题

• 跨语言实现复用：接口定义与实现语言分离，同一份 WIT 可以成为不同语言绑定生成的输入。
• 复合数据传递：记录、列表、字符串和结果类型在接口层有明确表达，不必让调用方直接猜指针和长度。
• 组件组合复用：一个组件的导出可以满足另一个组件的导入，组合关系能在接口层被检查。
• 能力边界复用：world 只声明需要的导入，宿主可以按接口提供文件、时钟、网络或自定义能力。

这也是它和“把多个 Wasm 文件放进同一个目录”之间的区别：目录只是文件组织，Component Model 的组合依赖是机器可读的接口关系。组件的内部实现可以变化，但只要仍然满足同一个边界，调用方就不需要重新理解内部内存布局。

不要把接口复用误认为自动兼容

Component Model 能把边界写清楚，却不会自动替你决定版本策略、业务语义和运行时支持。比如把 string 改成枚举、改变错误含义，或者把一个可选字段变成必填字段，都可能影响已有实现；接口能被解析，不等于旧组件在业务上仍然正确。

采用时可以按下面的顺序判断：

1. 先把真正需要共享的类型和函数收窄成一个接口，避免把宿主细节全部暴露出去。
2. 再用 world 列出组件的最小导入与导出，检查是否存在不必要的系统能力依赖。
3. 最后确认目标语言、绑定生成器和运行时都支持所需的 Component Model 能力，再安排版本与回归策略。

如果你的问题只是同一语言内的普通函数调用，直接使用该语言的包或库通常更简单；如果要让不同语言、不同宿主或不同组件共享清晰边界，WIT 与 world 才体现出额外价值。

常见问题

WIT 是不是一种新的业务编程语言？

不是。WIT 主要描述 Component Model 的接口、类型和 world，不负责实现业务行为。真正的业务代码仍由目标语言编写。

有了 world 就不需要宿主了吗？

不需要。world 只是声明组件需要什么和提供什么，宿主或其他组件仍要实现并连接这些导入，组件才能在具体环境中运行。

Component Model 是否只能用于 WASI？

不是。WASI 提供了一组常用系统接口，但 WIT 也可以定义自定义接口和 world。是否适合使用，取决于目标运行时和工具链的支持范围。

接口定义相同就一定能无缝替换吗？

不一定。还要检查版本、错误语义、资源生命周期、运行时能力和宿主策略。机器可读的接口能减少猜测，但不能代替兼容性设计。