6.5 组件模型

6.5 组件模型

本节摘要：组件模型是 Wasm 互操作的终极形态：组件（component）是携带完整接口元数据的可组合单元，WIT 接口描述语言定义契约，类型系统跨越语言鸿沟。本节用一份 WIT 文件走完 Rust 到 JavaScript 的拼箱全流程，并解释它为何被称为"字节的包管理器"。

组件模型（Component Model）的定义可以先立在这里：组件是在核心模块之上封装了接口描述的可组合部署单元——核心模块管"怎么算"，组件层管"跟谁算、按什么契约算"。如果说核心 Wasm 是字节形态的集装箱标准，组件模型就是集装箱运输的联运单证体系：货物不再裸奔，每箱货自带规格书，码头凭单据对接，无需开箱验货。

WIT：把接口写成合同

WIT（WebAssembly Interface Types）是组件模型的接口描述语言。它短小、声明式、语言无关，一份合同甲乙双方各自认领：

package demo:billing;

world payment-gateway {
  import host-clock: interface {
    now: func() -> u64;
  }

  export charge: interface {
    record invoice {
      account: string,
      cents: u64,
    }
    enum result-kind { ok, insufficient-funds, invalid-account }
    // 按发票收款，返回结果种类与余额
    charge: func(inv: invoice) -> result-kind;
    balance: func(account: string) -> u64;
  }
}
​

这份合同有三处值得细看。record 与 enum 让"结构化数据"出现在接口签名里——核心 Wasm 只认数字与引用，把字符串、记录搬上接口层正是组件模型的核心贡献。import 与 export 的双向声明完整刻画了组件的生存上下文：它需要宿主提供时钟（host-clock），并对外提供收款能力（charge）——这份完整画像在上一章实例化模型里只是朴素的导入导出表，在这里成为可审计的正式文件。world（世界）概念把"一组进出口契约"打包命名，一个组件实现一个 world 的 export 侧，一个宿主实现 import 侧。

端到端：从 Rust 组件到 JavaScript 宿主

把上面的合同走完整个流水线。Rust 侧实现 export 接口：

// Cargo.toml 声明组件目标与 wit 绑定生成
use demo_billing::payments::charge::{Charge, Invoice, ResultKind};

struct Gateway;

impl Charge for Gateway {
    fn charge(&self, inv: Invoice) -> ResultKind {
        if inv.cents > self.balance_of(&inv.account) {
            return ResultKind::InsufficientFunds;
        }
        // ... 扣款逻辑
        ResultKind::Ok
    }
    fn balance(&self, account: String) -> u64 { /* ... */ }
}

// 构建产出即组件字节：wasm32-wasip2 目标直接产出组件
​

$ cargo build --target wasm32-wasip2 --release
$ wasm-tools component wit target/wasm32-wasip2/release/billing.wasm  # 体检：合同是否兑现
​

构建产物已经是组件——wasip2 目标在编译期把 WIT 合同嵌进组件元数据。wasm-tools 用同一份 WIT 反向核对：接口名、函数签名、类型结构，任何一处不兑现即验关失败。

JavaScript 侧消费组件，工具从合同自动生成类型完整的绑定：

$ npm install --save-dev @bytecodealliance/jco
$ jco transpile billing.wasm -o bindings
​

import { Charge } from "./bindings/demo-billing-charge.js";

const gateway = new Charge(
  (cents) => new Date().getTime(),   // host-clock 的 JS 实现
  { /* 账户后端 */ }
);

const kind = gateway.charge({ account: "acct-42", cents: 1999 });
​

串起来看这套流水线的分工：WIT 是唯一契约，Rust 编译器与 jco 各自从它生成自己语言的绑定，字符串与记录的序列化由生成代码自动处理——第五章手工搬内存的全部繁琐在这里消失了。契约变更时改 WIT、两端重新生成，编译器立刻指出所有失配点——接口演化从"心照不宣"变成"类型检查"。

图 6-D：组件拼箱的分层结构

图 6-E：组件模型的分层解剖

定位与现状：为什么说它是地平线

组件模型的野心值得用一句话点破：它在定义"字节的包管理器"。npm 之于 JavaScript、crates 之于 Rust，都只服务单一语言；组件模型定义的是所有语言共享的分发单元——未来注册表里的每个组件都带着 WIT 合同，任何语言的宿主都能按合同调用，跨语言库生态的地基由此铺下。

现状的清醒判断同样必要：核心规范与主流工具链（Rust 的 wasip2 目标、wasm-tools、jco）已经能跑通端到端，WASI 预览二建立在它之上；但注册表与版本治理生态仍在建设，各语言工具链成熟度参差。生产姿态沿用分层策略：服务端新链路可以试点（收益是实打实的绑定自动化），跨组织的组件分发等生态定型。学它不必等它——WIT 与合同思维是纯收益，今天就值得写进设计文档。

本节要点回顾

• 组件等于核心模块加合同：核心管计算，组件层管接口与组合，两者以适配器相接；
• WIT 是唯一契约：record 与 enum 让结构化数据上接口，world 完整刻画进出口；
• 绑定自动化：Rust 与 JavaScript 各自从 WIT 生成类型完整的绑定，手工搬内存的繁琐清零；
• 契约演化即类型检查：改合同、重生成、编译器点名失配——接口变更不再心照不宣；
• 生产姿态分层：服务端新链路可试点，跨组织分发等生态；WIT 思维即刻可学可用。

增补舱位巡检完毕。下一章驶入真实航线：Web 与服务端的完整实战，把六章装备变成交付物。