你以为 Wasm 只能在浏览器里跑？今天 Rust 把它跑进微控制器了

很多人以为 WebAssembly 的终点是浏览器。

其实它的边界早就被撑破了。

FOSDEM 2026 的一场演讲透露了一个让现场工程师意外的数据：在 Nordic nRF52 和乐鑫 ESP32 这种只有几百 KB 内存的微控制器上，Rust 编译出的 Wasm 模块已经能稳定运行了。不是 demo，不是实验室数据，是有人在生产设备上跑起来的真实案例。

为什么是 Rust？

Rust 是目前对 WebAssembly 支持最完善的语言，没有之一。rustc 直接输出 wasm32 目标，wasm-pack 一键编译，wasm-bindgen 处理 JS 互操作，三个工具加在一起就是目前最顺的 Wasm 开发链条。FOSDEM 那场演讲里，研究团队甚至专门提到，整个嵌入式 Wasm 技术栈全部是 Rust——从 Embassy 固件层、嵌入式 HAL，到 Wasm 工具链，再到运行时本身。

这对嵌入式工程师意味着什么？安全更新不用再重刷固件了。Wasm 模块可以在运行时动态加载，不影响主固件。这意味着 OTA 更新可以做到只更新业务逻辑层，而不触碰底层驱动。烧录失败导致设备变砖的风险也下来了。开发时同样受益——同一份 Wasm 模块可以在开发电脑上跑，也可以在目标设备上跑，测试环境和生产环境高度一致。

但微控制器跑 Wasm 有个现实问题：内存。

主流 Wasm 运行时对内存的消耗差异很大。研究团队在 FOSDEM 上对比了四套方案：wasmtime（最成熟但体积大）、wasmi（解释器路线、轻量）、tinywasm（极端轻量，专为 MCU 设计）和 WAMR（字节码联盟出品，支持嵌入式集成）。在 64KB RAM 的目标上，tinywasm 能跑起来的固件，wasmtime 可能直接 OOM。wasmi 居中，但它的燃料计量功能在智能合约场景里几乎是刚需。

FOSDEM 那场演讲的 benchmark 结果值得细看。以 Nordic nRF52840 为例，wasmtime 冷启动约 2.3ms，wasmi 约 0.8ms，tinywasm 约 0.4ms——但 tinywasm 的功能集也最受限，不支持 wasm-bindgen 那一套。如果你的固件只需要跑一段加密验签逻辑，tinywasm 够用；如果还要和上位机做复杂数据交换，wasmi 的功能完整性更有保障。

这里有个取舍需要想清楚：你要的是最极致的体积，还是最完整的功能。wasmtime 背靠字节码联盟，生态最成熟，但二进制体积在嵌入式场景里是个障碍，研究团队的建议是先用 wasmi 验证功能可行性，确认跑通了再根据硬件规格选运行时——如果 flash 吃紧，再切 tinywasm 做裁剪。

Rust 工程师在 MCU 上跑 Wasm 还有个额外优势：没有 GC。Rust 的所有权模型决定了它没有垃圾收集器，这意味着运行时停顿对实时性没有影响。对那些对响应延迟有严格要求的控制逻辑来说，这是硬性需求。用 C 也能做到无 GC，但 C 的内存安全问题在嵌入式领域是个长期隐患——固件 bug 导致的安全漏洞，修起来比重刷固件还麻烦。

Rust 嵌入式 Wasm 的现状是：工具链基本就绪，生产案例开始出现，但离主流化还有距离。主要瓶颈是工具链对 MCU 场景的优化还不够细致——比如 no_std 环境下 std 库的兼容处理，对新手上车的门槛仍然不低。另外嵌入式 Wasm 的安全认证体系也还在建立中。今天 ADAR One 用 Rust 拿到了 IEC 61508 安全认证，这是嵌入式 Rust 的一个里程碑，但它面向的是工业传感器场景，不是通用 MCU。

如果你的团队在搞 IoT 设备，或者固件需要支持插件机制，Rust 加嵌入式 Wasm 值得认真看。不是噱头，是有人在生产环境里跑出来的。

下一步：先在普通开发板上用 wasmi 跑通第一个 wasm 模块——不需要 Nordic 或 ESP，买个树莓派 Pico 就够。