Docker 在很长一段时间里只负责运行 Linux 容器，底层依赖 runc 或 containerd 启动标准进程。WebAssembly（WASM）则是另一套与平台无关的字节码格式，最初来自浏览器。两者看似没有交集，但随着 WASI（WebAssembly System Interface）规范的成熟，WASM 模块已经可以脱离浏览器访问文件、网络、随机数等系统能力。容器生态顺势引入了对 WASM 模块的支持，使开发者可以用熟悉的 Docker 命令启动一个只有几百 KB 的 WASM 应用，而无需构建完整的操作系统镜像。
这种组合的核心思路是让 containerd 这类容器管理器在启动任务时，不再只调用 runc，而是可以选择 WasmEdge、wasmtime 等 WebAssembly 运行时。于是 OCI 镜像可以携带 .wasm 文件，通过不同的运行时类型来执行。下面从底层机制、模块构建、镜像打包和实际运行几个角度展开说明。
Docker 对 WASM 的支持原理
传统容器运行时的工作链路大致是 Docker CLI 将请求发送给 containerd，containerd 再通过 shim 进程调用 runc 创建容器。为了支持 WASM，社区开发了 runwasi 项目，它相当于一个定制化的 shim，职责是把原本交给 runc 的启动任务转交给 WebAssembly 运行时，例如 WasmEdge 或 wasmtime。runwasi 负责解析 OCI 镜像中的 WASM 模块，并按 WASI 规范为其准备标准输入输出、环境变量、挂载目录等上下文信息。这样一来，Kubernetes 和 Docker 都能在不改变上层接口的情况下调度 WASM 工作负载。
OCI 镜像本身并没有强制规定只能存放 Linux 可执行文件。只要镜像清单中声明了正确的平台标识，containerd 就能识别出这个镜像属于 WASM 类型。这个平台标识通常写作 wasi/wasm，它告诉容器引擎不要尝试寻找 ELF 可执行文件，而是把镜像根目录中的 .wasm 文件交给对应的 WebAssembly 运行时。比如一个标注为 wasi/wasm 的镜像，在 Docker Desktop 中会被自动路由到内置的 WASM 运行时，而在 Linux 服务器上则可能需要手动指定 --runtime 参数。
目前主流的 WebAssembly 运行时对 WASI 的支持程度并不完全一致。WasmEdge 更偏向云原生场景，提供了较完整的网络 socket 支持和 TensorFlow 推理扩展；wasmtime 由 Bytecode Alliance 维护，严格遵循 WASI 规范，适合作为通用执行引擎；WAMR 则更轻量，常用于嵌入式设备。Docker 通过插件或运行时配置可以同时挂载多个 WASM 运行时，按需切换。
创建并编译一个 WASM 模块
要让 Docker 运行 WASM 模块，首先得有一个编译好的 .wasm 文件。以 Rust 为例，它原生支持 wasm32-wasi 目标，不需要额外安装复杂的工具链。先安装对应的编译目标：
rustup target add wasm32-wasi
接着创建一个最小的 Rust 项目。在 Cargo.toml 中声明包信息，然后编写入口文件，打印一行文字并读取一个环境变量以演示 WASI 的交互能力。代码如下：
use std::env;
fn main() {
println!("Hello from WASM inside Docker");
if let Ok(val) = env::var("GREETING") {
println!("Environment variable GREETING = {}", val);
}
}编译命令指定目标平台为 wasm32-wasi，生成的文件默认位于 target/wasm32-wasi/release/ 目录下。如果想减小体积，可以使用 release 模式并开启 LTO 优化。编译完成后，可以用 wasmtime 或 wasmedge 在本地先验证模块是否能正常运行，确认没有依赖宿主操作系统的特殊调用后再交给 Docker。
将 WASM 模块打包为 OCI 镜像并运行
Docker 镜像的打包并不复杂，只需要把 .wasm 文件放入镜像根目录，并设置正确的入口点。由于 WASM 模块不依赖任何 Linux 基础库，可以直接使用 scratch 作为基础镜像，这样最终镜像体积可以控制在几百 KB 以内。Dockerfile 示例如下：
FROM scratch COPY target/wasm32-wasi/release/hello_wasm.wasm /hello_wasm.wasm ENTRYPOINT ["/hello_wasm.wasm"]
构建镜像时需要显式指定平台为 wasi/wasm，否则 Docker 会默认尝试构建 Linux 平台镜像，并在后续运行时找不到合适的可执行文件。完整的构建命令如下：
docker build --platform wasi/wasm -t hello-wasm:latest .
运行镜像时，如果是在 Docker Desktop 环境，通常只需加上平台参数，Docker 会自动选择 WASM 运行时。命令如下：
docker run --platform wasi/wasm --rm hello-wasm:latest
在 Linux 服务器上，由于 Docker Engine 本身不包含 WASM 运行时，需要先安装 runwasi 并注册对应的运行时处理器。以 WasmEdge 为例，安装完成后可以执行：
docker run --runtime=io.containerd.wasmedge.v1 --platform wasi/wasm --rm hello-wasm:latest
如果希望容器启动时读取环境变量，可以追加 -e GREETING=world 参数。运行时 shim 会把环境变量注入 WASM 模块的 WASI 上下文，程序内部通过 env::var 就能读到值。这个行为与传统 Linux 容器非常相似，但底层没有 fork 出任何 Linux 进程，启动延迟通常可以控制在几毫秒到几十毫秒之间。
WASM 容器与传统容器的差异与选型
从运行效果来看，WASM 容器和传统 Linux 容器都能用 docker run 启动，但两者在隔离模型、资源开销和系统调用能力上有本质区别。传统容器通过内核命名空间和 cgroup 实现隔离，每个容器运行的是真实的 Linux 进程；而 WASM 容器由 WebAssembly 运行时在用户态提供沙箱，模块内部无法直接执行任意系统调用，所有对外部资源的访问都必须经过 WASI 接口。这种设计让 WASM 容器天然具备较强的安全边界，即便模块中存在恶意代码，也很难突破运行时沙箱去攻击宿主内核。
在资源消耗方面，WASM 模块通常是静态编译的，不包含操作系统库和用户态工具链，因此镜像体积可以从传统容器的几十 MB 缩小到几百 KB。冷启动时间也从几百毫秒降至几十毫秒甚至更低，内存占用同样大幅减少。对于需要频繁扩缩容、瞬时执行短任务的场景，比如边缘计算节点、Serverless 函数和物联网网关，这种差异会直接转化为成本和响应速度的优势。
但 WASM 容器并非万能替代品。WASI 目前对网络、进程、线程等系统接口的支持仍然有限，很多依赖 Linux 系统调用或动态链接库的应用无法直接迁移到 WASM。另外，模块必须事先编译为 wasm32-wasi 目标，这意味着 C、Rust、Go 等语言需要显式适配，而 Java、Python 等语言的支持还处于发展阶段。因此，WASM 容器更适合计算密集、逻辑轻量、对启动速度敏感且能够接受受限系统接口的工作负载，传统 Linux 容器则继续承载需要完整操作系统语义的应用。
综合来看，Docker 运行 WASM 模块并不是要取代传统容器，而是为某些特定场景提供一种更轻量的执行单元。理解 containerd 的 shim 机制、OCI 平台标注和 WASI 的能力边界之后，开发者就可以在合适的场景中把编译好的 .wasm 文件打包成镜像，用熟悉的 Docker 命令完成部署和运维。
