Docker 镜像动辄 GB 级；完整游戏引擎竟可编译为仅 35MB 的 WASM

# Docker 镜像高达数百 MB；而完整的游戏引擎编译为 35MB WASM 来源：https://bogomolov.work/blog/posts/wasm-vs-docker/ 几个小时前我将一个游戏骨架导出为 WebAssembly，对生成的产物大小感到惊讶。这是一个完整的 3D 引擎——包含 GL 兼容性渲染器、Jolt 物理引擎、GDScript 运行时、Ink 叙事解释器。二进制文件：35MB。可在任何浏览器中运行，无需安装。 Facebook 的主页加载量是 44MB。这个游戏引擎是 35MB。 ## # (https://bogomolov.work/blog/posts/wasm-vs-docker/#try-it) 试一试 全屏 (https://pub-cab470135ad64bbf9490e4c1ce5fa431.r2.dev/stanica/index.html)，WASD，Esc。 ###### # (https://bogomolov.work/blog/posts/wasm-vs-docker/#the-thing-that-weighs-less-than-a-base-image) 比重比基础镜像更轻的东西 `python:3.14-slim-trixie` – 精简的基础镜像，在你添加任何单个依赖之前 – 大小为 144MB。即使是使用 uv 精心构建的最小化版本 (https://bogomolov.work/blog/posts/docker-uv/) 也达到了 282MB。 ## # (https://bogomolov.work/blog/posts/wasm-vs-docker/#landscape) 现状 来自我的浏览器和本地 Docker 缓存的大小数据： 项目大小 Google 主页（所有资源，43 个请求）10MB 本游戏（Godot 4，完整引擎）35MB Facebook 主页（所有资源，379 个请求）44MB livekit/livekit-server（Go, WebRTC）75MB python:3.14-slim-trixie 144MB python:3.14-slim-trixie + 最小依赖 282MB 我工作中的 REST API 300–400MB node:latest（每周拉取 19M 次）421MB ghcr.io/gohugoio/hugo 423MB 我工作中基于 Python 的 AI 智能体 1.45GB Hugo: 423MB 用于生成静态 HTML。游戏引擎仅为 35MB 😌 Go 二进制文件（livekit 为 75MB）已经非常接近了。 ## # (https://bogomolov.work/blog/posts/wasm-vs-docker/#the-open-question) 待解的问题 一方面，Go 可能是一个解决方案，但 `wasip1` 仍处于预览阶段——标准运行时中没有套接字（sockets），没有线程。Zig 更接近一些，但也尚未达到。目前只有 Rust 和 C/C++ 是实际可行的选项。 另一方面 —— Cloudflare Workers 可以加载 WASM 模块，containerd 有 runwasi，Kubernetes 有 kwasm 实验，WASI 运行时也已存在。 那么为什么 WASM 的采用停滞不前？传输大小的优势已经很明显了：大约小 10 倍。为什么这还不足以成为标准实践？ 就像几年前的 ARM 节点一样：更便宜、密度更高、广泛可用——但仍然不是默认选择。