WASI 0.3 把异步写进 ABI：WebAssembly 服务端插件化终于补上关键一环

过去几年，WebAssembly 一直被描述为“比容器更轻”“可以在浏览器之外运行”的新技术。

但对于真正做后端架构的人来说，能不能运行从来不是最关键的问题。真正决定一项技术能否进入生产系统的，是另外几个问题：

不同语言编写的代码如何调用彼此？接口如何定义？异步任务如何跨模块传播？插件可以访问哪些文件和网络？运行失败后会不会拖垮主服务？版本升级时如何保持兼容？

2026 年 6 月 11 日，WASI 0.3 正式发布，将原生异步能力引入 WebAssembly Component Model。随后在 8 月 11 日发布的 WASI 0.3.1 中，又加入了 map<K, V>、implements 和 external-id 等组件模型能力。目前 WASI 0.3 已被官方列为稳定且当前的版本。(Bytecode Alliance)

这次升级的意义，并不只是多了几个语法。

它真正解决的是：WebAssembly 组件如何在保持隔离的同时，完成跨语言、跨组件、可组合的异步调用。

一、先别急着谈 WASI，先分清三个概念

很多人会把 WebAssembly、Component Model 和 WASI 混为一谈。

实际上，它们分别解决不同层面的问题。

WebAssembly 核心模块的函数边界主要处理 i32、i64、f32、f64 等基础类型。如果需要传递字符串，往往要把字符串转换成线性内存中的地址和长度；如果不同语言对字符串、数组、对象的内存布局理解不一致，互操作就会变得复杂。

Component Model 在核心 WebAssembly 之上增加了更丰富的接口类型，并通过 WIT，也就是 WebAssembly Interface Types，描述组件导入和导出的能力。Canonical ABI 则负责规定这些高级类型在底层如何传递。(WebAssembly 组件模型)

WASI 进一步提供访问外部世界的标准接口，例如文件系统、Socket、时钟、随机数和 HTTP。平台可以选择只向组件暴露部分 WASI 能力，而不是直接让组件继承宿主进程的全部权限。(WebAssembly 组件模型)

graph TB
    A[业务代码] --> B[WIT 接口]
    B --> C[Component Model]
    C --> D[Wasm Runtime]
    E[WASI 系统接口] --> D
    D --> F[文件]
    D --> G[网络]
    D --> H[时钟]
    D --> I[HTTP]

可以把它简单理解为：

WebAssembly 负责执行，Component Model 负责连接，WASI 负责访问系统资源。

二、WASI 0.2 已经能异步，为什么还需要 0.3

WASI 0.2 并不是完全不支持异步。

它提供了 pollable、input-stream、output-stream 和 poll 等抽象，可以表达某项操作暂时没有完成，需要等待就绪事件。

当一个组件直接与宿主交互时，这套模式基本可以工作。

问题出现在组件开始组合之后。

假设调用链是：

组件 A → 组件 B → Host I/O

组件 A 调用组件 B，组件 B 又向宿主发起网络请求。网络操作完成后，宿主需要唤醒等待结果的任务。

在 WASI 0.2 中，pollable 属于某一个具体组件实例。宿主产生的就绪信号只能先回到组件 B，组件 B 还需要维护自己的事件循环，再把状态传递给组件 A。

如果调用链继续加深：

组件 A → 组件 B → 组件 C → Host I/O

中间的每个组件都可能需要承担状态转发职责。异步状态无法自然穿过组件边界，这被称为 Sandwich Problem，也就是“三明治问题”。(WASI)

问题的本质不是某个 API 不够好用，而是异步能力放错了层级。

只要异步仍然是某个 WASI 资源的特性，而不是组件调用协议本身的能力，那么组件之间就很难真正组合。

三、WASI 0.3 的核心变化：异步进入 Canonical ABI

WASI 0.3 将异步能力下沉到 Component Model 的 Canonical ABI 中，并引入三个关键原语：

这些原语不再属于某个组件自己的事件循环。

组件只需要声明某个函数是异步的，真正的挂起、恢复、调度和唤醒传播由 Runtime 负责。异步状态可以穿过多个组件边界，而不要求每个中间组件都维护一套事件转发机制。(Bytecode Alliance)

1. async func

WIT 接口现在可以直接声明一个异步函数：

package demo:risk@0.1.0;

interface checker {
    record order {
        order-id: string,
        amount: u64,
        user-level: string,
    }

    variant decision {
        pass,
        review(string),
        reject(string),
    }

    check: async func(input: order) -> result<decision, string>;
}

world risk-plugin {
    export checker;
}

这个接口并没有规定组件必须使用 Rust、JavaScript、Python 还是其他语言开发。

它只规定：

输入是什么，输出是什么，错误如何表达，以及这次调用可能异步挂起。

绑定生成器可以把它映射为不同语言习惯的异步形式，例如 Rust 的异步函数、JavaScript 的 Promise 或 Python 的协程。(WASI)

2. stream<T>

stream<T> 表示一段可以逐步产生或消费的数据。

它不只适用于字节流，也可以表示结构化数据流，例如：

• stream<u8>：文件内容、HTTP Body、TCP 数据；
• stream<record>：逐条返回查询结果；
• stream<directory-entry>：异步遍历目录；
• stream<tcp-socket>：持续接收新连接。

关键在于，流本身可以跨组件边界传递。

中间组件可以把一个流继续交给下一个组件，不需要自己不断轮询并转发每一段数据。

3. future<T>

future<T> 表示未来会完成的一次结果。

WASI 0.3 经常将 stream<T> 和 future<T> 组合起来使用：

• stream<T> 负责传输数据；
• future<T> 负责告诉调用方最终是成功、失败还是被中断。

这样，即使调用方没有把整个流读取完，也能单独获得这次操作的最终状态。

四、wasi:io 被移除，不是删除能力，而是重新分层

WASI 0.3 移除了原来的 wasi:io 包。

这并不意味着输入输出能力消失，而是原来由 wasi:io 表达的异步概念，已经被下沉为 Component Model 的基础能力。

对应关系大致如下：

过去一次异步连接可能需要：

1. 调用 start-connect；
2. 获得一个可轮询对象；
3. 等待对象就绪；
4. 调用 finish-connect；
5. 得到最终结果。

在 WASI 0.3 中，可以直接表达为：

connect: async func(
    remote-address: ip-socket-address
) -> result<_, error-code>;

复杂的异步状态机并没有消失，只是从业务组件和接口设计中移到了 Runtime。

这与高级语言隐藏线程调度、协程恢复的思路类似：开发者表达意图，运行时负责执行细节。(WASI)

五、HTTP 接口终于不再像一套手写状态机

WASI 0.3 中变化最明显的领域之一是 wasi:http。

WASI 0.2 为了表达请求、响应、Body、Trailer 和异步结果，使用了多个资源类型，包括：

• incoming-request
• outgoing-request
• incoming-response
• outgoing-response
• incoming-body
• outgoing-body
• future-trailers
• future-incoming-response
• response-outparam

WASI 0.3 将这些结构大幅简化为统一的 request 和 response，Body 使用 stream<u8>，Trailer 和完成状态通过 Future 表达。

HTTP Handler 也变成了更容易理解的形式：

handle: async func(
    request: request
) -> result<response, error-code>;

与此同时，原来的 wasi:http/proxy 被 wasi:http/service 取代，并新增了 wasi:http/middleware。

middleware 同时导入和导出 Handler，这意味着鉴权、限流、日志、Header 改写、内容过滤等能力可以被制作成独立组件，再与业务组件组合。(WASI)

例如一个请求链路可以由多个不同语言实现的组件组成：

graph LR
    A[客户端请求] --> B[鉴权组件]
    B --> C[限流组件]
    C --> D[业务组件]
    D --> E[返回响应]
    F[Wasm Runtime] --> B
    F --> C
    F --> D

这些组件既可以由 Runtime 放在同一进程内组合，也可以根据平台实现被部署成不同形态。

当调用发生在同一个 Runtime 内部时，组件之间不一定需要经过真实网络连接。官方将这种能力称为 Service Chaining，也就是将多个服务能力直接组合为组件调用链。(Bytecode Alliance)

不过，这并不意味着应该把所有微服务重新塞回一个进程。

如果两个模块需要独立扩缩容、独立发布、独立故障隔离，网络边界仍然有价值。组件组合更适合解决插件、扩展点和细粒度能力复用，而不是无条件取代微服务。

六、WASI 真正有价值的地方，是能力安全

传统进程通常会继承启动用户拥有的权限。

如果一个 Java 服务可以读取某个目录、访问内网数据库、读取环境变量，那么加载到这个服务中的第三方代码，往往也可能间接获得这些能力。

WASI 采用的是能力安全模型。

一个组件启动时默认没有访问外部世界的环境权限。它能否读取文件、打开网络连接、获取环境变量或调用某个宿主接口，取决于 Runtime 是否向它提供了相应能力。(WASI)

例如，一个订单计价组件可能只需要：

• 接收订单参数；
• 读取当前时间；
• 返回计价结果。

那么它就不应该拥有：

• 文件系统访问能力；
• 任意网络访问能力；
• 数据库账号；
• 宿主进程的全部环境变量；
• 执行系统命令的能力。

这与“先给进程完整权限，再通过代码约定不要乱用”完全不同。

组件的导入接口本身就是一份可以静态检查的能力清单。

假设一个组件的 WIT 定义只导入时钟接口，没有导入网络和文件系统接口，那么从组件契约上就可以看出，它不应该直接访问网络和文件。

当然，能力模型并不等于绝对安全。

生产环境仍然需要限制：

• 最大内存；
• 最大执行时间；
• 最大并发数；
• 最大输出大小；
• 网络目标白名单；
• 文件目录白名单；
• 组件签名与摘要；
• Runtime 自身的安全更新。

Wasm 可以限制组件“能做什么”，但宿主仍然要限制它“能消耗多少”。

七、它更像标准化插件 ABI，而不是更小的 Docker

把 WASI 理解成“轻量级容器”容易产生误判。

容器解决的是进程级封装问题，包括：

• 文件系统镜像；
• 依赖环境；
• 网络命名空间；
• 进程隔离；
• 资源限制；
• 部署与调度。

Component Model 解决的是组件级调用问题，包括：

• 接口如何声明；
• 类型如何跨语言传递；
• 组件如何导入和导出能力；
• 组件之间如何组合；
• 异步如何跨边界传播；
• 宿主如何按需授权。

因此，WASI 0.3 最适合进入的，并不是所有后端服务，而是系统中的扩展边界。

适合的场景

暂时不适合的场景

• 强依赖完整 JVM 生态的业务核心；
• 大量使用反射、动态类加载和本地库的框架；
• 需要复杂数据库事务的主业务服务；
• 长时间保持大量内存状态的应用；
• 需要直接访问大量操作系统特性的程序；
• 团队无法维护组件版本、权限和运行时治理的平台。

WASI 不是让现有系统全部重写，而是为过去难以隔离的插件代码增加一个更清晰的运行边界。

八、WASI 0.3.1 又补上了两个重要能力

2026 年 8 月 11 日发布的 WASI 0.3.1，是 0.3 系列的第一个补丁版本。

它采用了 map<K, V> 类型，以及 implements、external-id 等组件模型特性。(GitHub)

1. map<K, V>

过去，WIT 中如果要表达字典，通常需要使用：

list<tuple<string, string>>

有了 map<K, V> 后，可以直接表达：

map<string, string>

这不仅减少了接口定义中的样板结构，也更容易映射到 Java 的 Map、Rust 的映射类型和 JavaScript 对象。

2. implements

大型系统中可能同时依赖同一种接口的多个实现。

例如，一个组件可能同时需要：

• 远程 Valkey 存储；
• 本地内存缓存。

它们可能都实现 Key-Value 接口，但对应不同实例。

implements 等能力让组件可以更明确地表达：导入的不是任意一个 Key-Value 接口，而是具有特定角色和标识的实现。

这一步看似只是接口语法增强，实际上对依赖注入、组件装配和大型组件图非常重要。

九、Java 项目现在应该怎么接入

对于 Java 开发者，需要先接受一个现实：

截至目前，WASI 官方语言支持表中，Java 通过 GraalVM 输出 WebAssembly Component 仍处于规划阶段。WASI 0.3 的语言生态也还在逐步落地：Rust 已有相关绑定，但部分能力仍依赖较新的工具链；JavaScript 的 0.3 支持仍带有实验性质。(WASI)

因此，现在不适合把现有 Spring Boot 服务直接编译成 WASI 0.3 组件。

更现实的路线是：

Java 继续负责主业务和平台治理，Wasm Runtime 负责执行受控插件。

graph LR
    A[Java 主服务] --> B[插件路由]
    B --> C[Wasm Runtime]
    C --> D[规则组件]
    C --> E[转换组件]
    C --> F[鉴权组件]
    G[组件仓库] --> B
    H[能力策略] --> C
    I[监控审计] --> C

第一阶段：选择一个低风险扩展点

不要从订单核心事务、支付链路或用户中心开始。

可以先选择：

• 文本格式转换；
• 数据脱敏；
• 自定义校验；
• 营销规则；
• 内容过滤；
• Header 处理。

这些功能通常输入输出明确，出现问题后也容易降级。

第二阶段：先定义 WIT，再写实现

传统项目经常先写 Java 接口，再根据具体实现不断修改。

组件系统更适合契约优先。

先定义：

• 输入类型；
• 输出类型；
• 错误类型；
• 是否异步；
• 是否需要流；
• 允许调用哪些宿主能力。

WIT 一旦作为平台契约发布，就应该像对外 API 一样进行版本管理。

第三阶段：建立组件清单

可以为每个组件维护一份平台自定义清单：

{
  "component": "risk-check",
  "version": "1.3.2",
  "digest": "sha256:replace-with-real-digest",
  "wasiVersion": "0.3.0",
  "world": "demo:risk/risk-plugin",
  "capabilities": {
    "filesystem": [],
    "network": [],
    "environment": [
      "RISK_LEVEL"
    ]
  },
  "limits": {
    "timeoutMs": 100,
    "memoryMb": 64,
    "maxOutputKb": 256
  }
}

这份清单不是 WASI 标准的一部分，而是平台自身的治理数据。

它至少应该记录：

• 组件名称和版本；
• 文件摘要；
• WIT World；
• WASI 版本；
• 所需能力；
• 执行超时；
• 内存限制；
• 发布状态；
• 回滚版本。

第四阶段：将宿主能力封装成窄接口

不要直接把数据库连接、Redis 客户端或完整 HTTP Client 交给插件。

更合理的方式是封装成业务能力：

interface customer-service {
    get-level: async func(
        customer-id: string
    ) -> result<string, service-error>;
}

组件只知道“查询客户等级”，并不知道数据来自 MySQL、Redis 还是远程服务。

这能够同时降低权限范围和基础设施耦合。

第五阶段：建立失败降级

任何插件调用都需要考虑：

• 组件不存在；
• 版本不兼容；
• 实例化失败；
• 执行超时；
• 内存超限；
• 返回数据不合法；
• Runtime 崩溃；
• 新版本性能退化。

主服务不能把插件当成永远可靠的本地方法。

即使它运行在同一台机器甚至同一进程中，也应该按照不可信依赖处理。

十、版本一致性会是当前最常见的坑

WASI 0.3 已经是稳定版本，但工具链并不意味着完全成熟。

官方迁移文档特别提醒：Runtime、WIT 定义、绑定生成器和构建工具需要指向一致的版本。如果版本不一致，组件实例化时可能出现难以理解的类型不匹配错误。

因此，不要在配置中只写：

wasi: latest

应该明确锁定：

• WASI 版本；
• Wasmtime 版本；
• wit-bindgen 版本；
• WIT 依赖版本；
• 组件构建镜像；
• 组件摘要。

以 Wasmtime 为例，官方文档显示 Wasmtime 46 及以上版本默认支持最终版 WASI 0.3.0；较早的 43 至 45 版本实现的是候选快照，通常还需要显式开启相关参数。

运行一个 HTTP 组件可以使用：

wasmtime serve plugin.component.wasm

但在生产环境里，仅仅“能运行”远远不够。

还应该固定 Runtime 镜像、组件摘要和 WIT 版本，避免开发环境与生产环境使用不同的组件协议。

十一、不要轻信“Wasm 一定比网络调用快”

当多个组件在同一个 Runtime 中组合时，确实可能绕过真实网络、TLS、连接池和远程序列化。

但这不代表组件调用必然是零成本。

它仍然可能涉及：

• Canonical ABI 类型转换；
• 宿主与组件之间的数据复制；
• 字符串编码转换；
• Runtime 调度；
• 内存边界检查；
• 异步任务切换；
• 组件实例化；
• 资源配额检查。

对于很小的函数，如果跨边界传递大量复杂对象，接口转换成本甚至可能高于业务计算本身。

因此，组件边界应该遵循两个原则：

第一，接口要粗粒度。

不要把一次完整业务操作拆成几十个细小组件调用。

第二，数据要明确。

尽量传递稳定的业务结构，不要把宿主内部对象模型完整暴露出去。

性能结论必须通过真实压测获得，而不是根据“Wasm 很轻”直接推导。

十二、Component Model 还没有到最终形态

虽然 WASI 0.3 已经稳定，但整个 Component Model 仍在走向 1.0。

官方公开的后续工作仍包括 ABI 改进、组件生命周期、工具链优化和正式规范化。当前组件组合工具也仍处于较早阶段，在接口版本匹配、依赖装配和复杂传递依赖方面还存在工程摩擦。(Bytecode Alliance)

这意味着团队应该区分两件事：

• WASI 0.3 的稳定接口可以开始试用；
• 整个生态尚未达到所有语言和框架都能无缝接入的程度。

现在适合做的是小范围、可回滚的生产试点，而不是制定“半年内全面 Wasm 化”的激进目标。

十三、生产落地必须补齐的治理能力

一个真正可用的 Wasm 插件平台，至少需要以下能力。

组件供应链

• 上传者身份认证；
• 二进制摘要校验；
• 组件签名；
• 漏洞扫描；
• 构建来源记录；
• 禁止运行未审核组件。

权限治理

• 默认不授予文件访问；
• 默认不授予网络访问；
• 环境变量使用白名单；
• 网络目标使用域名或地址白名单；
• 不同租户使用不同能力策略。

资源治理

• 超时中断；
• 内存上限；
• 并发上限；
• 输入大小限制；
• 输出大小限制；
• 单租户配额。

可观测性

• 组件版本；
• 调用次数；
• 成功率；
• 执行耗时；
• 超时次数；
• 内存峰值；
• 错误类型；
• 宿主能力调用记录。

发布治理

• 灰度发布；
• 按租户放量；
• 新旧版本并存；
• 快速回滚；
• 自动熔断；
• 失败时回退到默认实现。

没有这些治理能力，Wasm 只是另一种可以被上传并执行的二进制文件，而不是安全的插件平台。

十四、WASI 0.3 真正改变的，是系统边界

WASI 0.3 最重要的变化，不是让某个基准测试又快了多少，也不是让 WebAssembly 更像 Linux。

它改变的是后端系统划分边界的方式。

过去，系统中常见的边界主要有三种：

• 方法边界；
• 进程边界；
• 网络服务边界。

Component Model 正在提供第四种边界：

可移植、强类型、按能力授权、可以跨语言组合的组件边界。

它比普通方法调用更容易隔离，比远程服务调用更轻量，又比传统动态链接库拥有更明确的类型和权限契约。

对于 Java 开发者而言，最理性的做法不是担心 Wasm 会不会取代 JVM。

JVM 仍然非常适合承载复杂业务系统、成熟框架和长期运行的服务。Wasm 更适合承担那些变化频繁、来源复杂、需要隔离、需要跨语言扩展的能力。

主业务继续运行在 JVM 中。

规则、插件、转换器、网关扩展和不可信代码，逐步进入受控的 Wasm Runtime。

这可能才是 WASI 0.3 最现实的生产路径。