WebAssembly 现在运行在比浏览器更多的服务器和边缘节点上，67% 的组织表示他们在生产环境中使用它。从两年前的 47% 跳跃式增长，使 Wasm 正式进入了无服务器函数和边缘计算工作负载的主流领域。

转变是如何发生的

当 WebAssembly 最初出现时，它的承诺是为浏览器提供一种快速、安全的方式来运行使用 JavaScript 以外的语言编写的代码。早期采用者构建了游戏和重型图形工具，但运行时仍停留在浏览器沙箱内。在过去的几年里，一系列平台改进——最显著的是组件模型（Component Model）——为跨语言集成打开了大门，消除了曾经让混合使用 Rust、Go 或其他语言变得极其困难的摩擦。

与此同时，云提供商和 CDN 开始提供基于 Wasm 的执行环境。到 2026 年，运行在服务器和边缘的 Wasm 工作负载将超过浏览器。

这些数字意味着什么

  • 冷启动时间 – 一个全新的 Wasm 实例可以在 10 毫秒内准备就绪；而典型的 Docker 容器仍需要几秒钟才能启动。对于请求驱动型 API 而言，这直接转化为用户感知的延迟。
  • 二进制文件大小 – 一个 Wasm 模块的大小通常在 2 MB 到 5 MB 之间。而一个相当的 Docker 镜像通常重达 100 MB 到 200 MB，这对于带宽受限的边缘节点至关重要。
  • 安全性 – 沙箱执行模型隔离了不可信的代码，允许平台在运行核心服务的同时运行第三方插件，而不会暴露宿主操作系统。
  • 可移植性 – 只要实现了规范，单个 Wasm 二进制文件就可以在任何宿主机上运行，无论底层操作系统或语言生态系统如何。

Wasm 的优势所在

组件模型允许用一种语言编写的模块公开一个定义良好的接口，供另一种语言导入。这使得构建插件系统变得切实可行，在插件系统中，用不同语言编写的模块可以相互协作，而无需编写自定义的胶水代码。

当今受益于 Wasm 的典型场景包括：

  • 边缘函数，用于转换 HTTP 请求、执行身份验证或运行轻量级 AI 推理。
  • 插件或扩展架构，第三方开发者提交必须在沙箱中运行的二进制文件。
  • 短寿命、无状态计算，例如图像缩放、数据验证或特性标志（feature-flag）评估。

限制了 Docker 的地位

Wasm 并不是容器的通用替代品。它的沙箱并不暴露完整的操作系统，这意味着：

  • 在内存或磁盘中维护状态的长运行服务仍然更倾向于使用容器。
  • 需要直接访问 GPU、专用内核模块或深度系统级集成的应用程序仍留在 Docker 或类似的运行时上。

由于这些限制，许多组织采用混合技术栈：Wasm 用于快速、廉价的边缘层，而容器用于重型后端服务。

下一步值得关注什么

  • 工具链成熟度 – 用于 Wasm 的调试、性能分析和可观测性工具仍处于追赶拥有数十年历史的 Docker 生态系统的阶段。

总结

WebAssembly 已从浏览器中的新鲜事物转变为现代无服务器和边缘基础设施的核心组成部分。其速度、极小的资源占用和内置的隔离机制，使其成为需要即时启动并在边缘廉价运行的工作负载的首选。对于其他所有内容——有状态服务、重型 GPU 任务、深度操作系统集成——容器仍然保持优势。