你以为 WASM 只能跑计算？今天它把浏览器异步体系也彻底原生化了

WebAssembly 承诺把高性能代码跑进浏览器，这条路一直没堵死——但缺了一个口。

WASM 代码里写文件读写、网络请求这类阻塞操作时，JavaScript 环境只能给出一个 Promise，然后两边的执行模型对不上：WASM 那边的执行流想要”等”，JavaScript 这边的执行流只能”回调”。这个裂缝，业内叫”async gap”。

2026 年，这个坑被正式填上了。

JSPI 是什么

JSPI = JavaScript Promise Integration，是 WebAssembly 的一个标准扩展。当一个 WASM 模块调用返回 Promise 的 JavaScript 函数时，引擎会暂停该模块的运行，等 Promise resolve 了再接着跑——整个过程对 WASM 代码是透明的。

说人话就是：Rust/C++ 代码里写的 async/await，现在可以原封不动编译成 WASM 在浏览器里跑。不用改代码，不用重写 I/O 层，不用绕回调地狱。

以前是什么样

WASI 0.2 时代，WASM 里想发 HTTP 请求，得这么写：

// WASI 0.2 风格：回调地狱
wasi::http::request_get(“https://api.example.com/data“, |result| {
match result {
Ok(response) => {
wasi::http::response_body(response, |body| {
// 嵌套…
});
}
Err(e) => { / 处理错误 / }
}
});

每多一层操作多一层嵌套，代码读起来像在解谜。

现在是什么样

WASI 0.3 + JSPI 支持后，同样的代码可以这么写：

// WASI 0.3 风格：async/await
let response = wasi::http::request_get(“https://api.example.com/data”).await?;
let body = wasi::http::response_body(response).await?;

这是 Rust 代码——编译成 WASM，直接在浏览器里跑，上下文切换对调用方完全透明。

谁最受益

最大的受益者是把 C/C++/Rust 的桌面软件迁移到浏览器端。

图像编辑器、CAD 工具、音频工作站、数据库引擎、游戏模拟器——这些软件有一个共同特点：内部大量用阻塞 I/O 写成，移植到 Web 的最大障碍就是这个 async gap。JSPI 关闭之后，这些应用可以用一个链接替代一次安装，在浏览器里直接跑，速度接近原生。

落地情况

Safari 27 beta 随带 JSPI 支持，加上 Chrome 和 Firefox，JSPI 现在是 Interop 2026 的重点方向之一——三大引擎都实现了同一套行为规范，团队写一次代码，部署到哪个浏览器都能跑。

WebAssembly 3.0 在 2025 年 9 月成为 W3C 标准，包含了垃圾回收、异常处理、尾调用、64 位内存和 128 位 SIMD。JSPI 的落地让整个标准体系终于补全了最后一块。

一个判断标准

想判断你关注的桌面软件能不能搬进浏览器，就看它的 I/O 层：如果是异步的、基于回调的——那 JSPI 之前就差不多能跑；如果是阻塞式的、假设同步返回的——那 JSPI 之后才有可能。

这个变化不会在某天突然宣布。真正的信号是：某个你本来以为必须下载安装的软件，突然有一天变成了一个链接，点开就在浏览器里运行。