写过前端的人都以为 WASM 组件只能在 Wasmtime 里跑，今天 jco 把这件事彻底搬进了 JS 环境里

铁锈·Rust工具链内容创作者 2026-09-12 12 阅读

配了三年 WASM，每次想在一个 JS 项目里跑一个用 Rust 写的 WASM 组件，都得先装个 Wasmtime 或者靠 wasm-pack 硬编译。今天字节码联盟官方出了个叫 jco 的工具链，用两行命令把这件事彻底原生化了——直接输出 ES 模块，Node.js 和浏览器里 import 就能跑。

核心是什么

jco（JavaScript Component Tools）是字节码联盟出的官方 JS 工具链，核心功能有两个：

路径一：把 WASM 组件转成 JS

npx @bytecodealliance/jco transpile my-component.wasm -o dist/

输出的 dist/my-component.js 实现了 Canonical ABI（把 WASM 的字符串、record、list lift/lowering 成普通 JS 值），Node.js 和浏览器里直接 import 就能调：

import { getUser } from "./dist/my-component.js";
const user = await getUser(42);
console.log(user.name);

这个路径不需要 Wasmtime，生成的 JS 通过 @bytecodealliance/preview2-shim 把 WASI 接口（filesystem/http 等）桥接到宿主运行时自己的 API 上。

路径二：把 JS 模块转成 WASM 组件

npx @bytecodealliance/jco componentize app.js --wit ./wit --world-name app -o app.component.wasm

底层用的是 ComponentizeJS + StarlingMonkey（SpiderMonkey 编译成 WASM 的 JS 引擎）。生成的 .component.wasm 可以和 Rust/C 写的组件组合，部署到 wasmtime serve、Wasmer、Spin 等任意组件宿主。

实际案例

一个典型的场景是：你在 Rust 里写了一个图像处理组件，编译成 .wasm，然后用 jco 把它 transpile 成一个 ES 模块，前端里这样调用：

import { processImage } from "./image-processor.js";
const result = await processImage(imageBlob);

整个过程不需要后端，没有 wasm-pack，没有交叉编译，组件在哪写的无所谓。

安全性这件事要拎清楚

这里有个坑要特别说清楚：

在 Wasmtime 里跑 WASM 组件，是硬件级别的沙箱隔离——WASM 线性内存和宿主机内存完全隔开，能力句柄是不透明的整数，任何越界操作直接被引擎 trap 掉。

jco transpile 出来的 JS 跑在 Node.js 里，是 V8 的 JavaScript 上下文。V8 提供内存安全和基于原型链的隔离，但不是能力沙箱。如果你的 Node.js 进程有 fs、net、child_process 权限，那些权限对 transpile 出来的代码同样可见，除非你根本没把它们传进去。

换句话说：安全保证从「运行时引擎强制」变成了「我只调用你给我的函数」。能力泄露的风险直接从 Wasmtime 的硬件层转移到了 jco 代码生成的正确性和宿主应用开发者的自律上。

所以如果你要用 jco 跑不可信的第三方 WASM 组件，确保你的宿主应用在进程级别做了权限收紧——别把 fs 权限留给 untrusted 代码。

适合谁用

前端开发者：想直接用别人编译好的 WASM 组件，不需要懂 Rust、不需要 wasm-pack
全栈工程师：JS 服务端想调用 WASM 写的核心算法，不需要在进程外面套 Wasmtime
不是谁：想在大规模生产环境跑不可信第三方 WASM 组件的，目前阶段还建议用 Wasmtime

结论

WASM 组件跑到 JS 环境里不再是 hack 了。字节码联盟的 jco 把这件事做成了官方标准路径——Rust/C 写的组件，用 jco transpile 吐出一个 ES 模块，前端里 import 就能调。唯一要记住的是安全模型不一样：沙箱从硬件层移到了 JS 上下文，跑不可信组件时宿主进程权限要收紧。

评论区

0 条评论

登录后可评论。