这周 Kimi 和 Fable 5 抢了所有头条。但有一件事被低估了：WASI 0.3 预览版上个月发布了，带来了异步 I/O 支持。对于 WebAssembly 在后端的未来，这可能是一个转折点。
为什么 Wasm 值得关注
Wasm 最颠覆的特性是冷启动速度。
Docker 容器的冷启动（拉镜像 → 解压 → 启动进程）至少要几百毫秒，Java 应用更是以秒为单位。Wasm 的冷启动是微秒级——因为 Wasm 模块就是一个编译好的字节码文件，不需要启动操作系统进程。
这在 Serverless 场景下是革命性的：用户请求到达 → 冷启动 Wasm 模块 → 处理请求 → 销毁。整个生命周期不到 1 毫秒。这是 Serverless 的终极形态——每个请求一个独立的、安全的、瞬时的执行环境。
WASI 0.3 的关键突破
之前 WASI 只有同步 I/O，这意味着你没法在 Wasm 里高效处理网络请求。WASI 0.3 的 wasi:io/poll 接口终于让异步 I/O 成为可能。
简单说：WASI 0.3 之前，Wasm 只能跑函数。之后，可以跑服务了。
另外，Wasm 的沙箱隔离是在语言 VM 层面的，不共享操作系统内核。和 Docker 相比，安全边界更强。这让它天然适合多租户平台——每个租户一个 Wasm 沙箱，比容器更安全也更便宜。
现实的差距
不吹不黑，Wasm 在后端的现实是这样的：
- Rust 支持最好——wasm32-wasip2 target 已经可用，Tokio 异步运行时也能编译到 Wasm
- Go 在追赶——Go 1.24 改进了 Wasm 支持，但 goroutine 调度还有限制
- Java 还在早期——GraalVM 可以编译到 Wasm，但生态（数据库驱动、HTTP 客户端）远未成熟
- 可观测性是盲区——日志、Metrics、Tracing 在 Wasm 里怎么做？目前没有标准方案
谁在用？
- Cloudflare Workers：最成功的 Wasm 服务端应用，每天处理万亿次请求
- Fermyon Spin：基于 Wasm 的 Serverless 框架，已经有一些企业 case
- Docker 官方宣布支持 Wasm 作为容器运行时的替代
我的判断
Wasm 在后端的定位不是"替代 Docker"，而是"替代那些 Docker 太重了的场景"：
- 边缘计算：CDN 边缘节点、IoT 网关——需要极快启动、极小 footprint
- 事件驱动短任务：Webhook 处理、数据转换、图片缩放——生灭在毫秒之间
- 多租户平台：每个租户一个 Wasm 沙箱，比容器更安全、更便宜
2027 年之前，应该会有一个用 Wasm 写的正经后端框架获得广泛关注。
在 Kimi K3 和 Fable 5 抢走所有注意力的这一周，Wasm 的进步显得很安静。但历史的经验是：那些安静进步的技术，往往最终影响更大。
参考来源：
评论
评论已关闭。