一个完整的3D游戏引擎有多重?答案是35MB。

开发者最近把Godot引擎导出为WebAssembly格式,结果让人意外:GL兼容渲染器、Jolt物理引擎、GDScript运行时、Ink叙事解释器——全部打包进去,二进制文件只有35MB。零安装,任何浏览器都能直接运行。

打开网易新闻 查看精彩图片

作为参照,Facebook首页加载量是44MB。一个能跑完整游戏的引擎,比刷一次社交动态还轻。

打开网易新闻 查看精彩图片

但这不是最讽刺的对比。看看Docker世界的"基础款":

python:3.14-slim-trixie,官方精简镜像,没装任何依赖,144MB。就算用uv精心构建最小版本,也要282MB。Hugo静态网站生成器423MB。LiveKit的Go二进制75MB,已经算接近了。

35MB vs 144MB,差距不是一倍两倍,是4到10倍的传输体积。

技术栈已经就位。Cloudflare Workers支持WASM模块,containerd有runwasi,Kubernetes在实验kwasm,WASI运行时遍地开花。但WASM adoption就是卡住了。

问题出在哪?不是技术成熟度。Go的wasip1还在预览阶段——标准运行时没socket、没线程。Zig接近可用,但也没完全到位。今天能正经干活的,还是Rust和C/C++。

作者抛出一个更扎心的类比:ARM节点。几年前就更便宜、更密集、到处都有——到现在还不是默认选项。

打开网易新闻 查看精彩图片

体积优势明明摆在这儿,为什么换不来主流地位?

可能答案藏在"足够好"的陷阱里。Docker镜像大是大,但CI/CD pipeline早就围绕它建好了,开发者懒得动。WASM的10倍体积优势,在千兆带宽面前显得不够痛——直到你按流量付费,或者服务百万并发。

另一个信号:游戏引擎能35MB搞定,说明运行时膨胀不是必然。是选择问题。Python生态的依赖地狱、容器层的冗余堆积,都是习惯堆出来的技术债。

WASM会不会走ARM的老路——优势明显,但迁移成本拖慢普及?或者某个云厂商突然按出站流量 aggressively 定价,倒逼一波迁移?

现在没人知道。但35MB这个数字,至少证明了另一种可能。