Docker 镜像的体积问题长期困扰着开发者——一个精简版 Python 基础镜像就要 144MB,加上依赖轻松超过 280MB。但 WebAssembly 正在改变这一局面。开发者 Sergey Bogomolov 最近将一个完整的 3D 游戏引擎导出为 WASM,惊喜地发现整个二进制文件只有 35MB,可以在任何浏览器中直接运行,零安装。

这个数字意味着什么?Facebook 主页加载 44MB 的资源,而他的游戏引擎只有 35MB。Go 语言的 livekit 服务器(包含 WebRTC 功能)达到 75MB,已经接近这个游戏引擎的体积。更惊人的是,一个 Python 基础的 AI Agent 在他的工作中达到 1.45GB——是游戏引擎的 40 倍。Hugo 静态网站生成器需要 423MB,而生成的结果只是静态 HTML。
| Item |
Size |
| Google homepage (all resources, 43 requests) |
10MB |
| this game (Godot 4, full engine) |
35MB |
| Facebook homepage (all resources, 379 requests) |
44MB |
| livekit/livekit-server (Go, WebRTC) |
75MB |
| python:3.14-slim-trixie |
144MB |
| python:3.14-slim-trixie + minimal deps |
282MB |
| REST API from my job |
300–400MB |
| node:latest (19M pulls/week) |
421MB |
| ghcr.io/gohugoio/hugo |
423MB |
| Python-based AI agent from my job |
1.45GB |
对比表格揭示了一个尴尬的现实:主流 Docker 镜像的体积远超普通网页。即便是 Go 语言的二进制文件也开始接近这个量级——livekit 的 75MB 已经和游戏引擎相当。这意味着如果用 WASM 替代容器,不仅可以大幅减少传输体积,还可能获得更好的跨平台兼容性。
然而 WASM 的采用并未成为标准实践。WASI 的 socket 和线程支持仍在预览阶段,只有 Rust 和 C/C++ 是目前真正可行的选择。Cloudflare Workers 已经可以加载 WASM 模块,containerd 有 runwasi,Kubernetes 有 kwasm 实验,WASI 运行时也已存在。这些基础设施已经就位,但开发者仍未大规模转向 WASM。
这个困境类似于几年前 ARM 节点的处境:更便宜、密度更高、广泛可用——却仍然不是默认选择。技术上的可行性并不等于采用率,这背后可能有学习曲线、生态系统成熟度、还是现有工作流程惯性等因素。但毫无疑问,35MB 的游戏引擎已经证明了 WASM 在体积上的优势是真实的。
来源:Sergey Bogomolov (https://bogomolov.work/blog/posts/wasm-vs-docker/)