2026年5月，开发者 Ivan Bogomolov 发布了一篇简短的帖子，在他的个人博客上指出了一件引人注目的事：一个完整的 3D Godot 4 游戏引擎，包含 GL Compatibility 渲染器、Jolt 物理、GDScript 运行时和一个叙事解释器，导出为 WebAssembly 后仅有 35MB。

作个比较：

• 默认的 Node.js Docker 镜像大小为 421MB。

• Facebook 的首页会加载 44MB 的资源。

• 这个游戏引擎比两者都小。

他的帖子提出了一个很自然的后续问题：如果一个完整的游戏引擎编译后只占到一个简陋 Docker 镜像的一小部分，WebAssembly 也能被用作游戏服务器的容器吗？

简短的答案是：还不行。原因如下。

什么是 WebAssembly？

WebAssembly（WASM）是一种二进制指令格式，旨在以接近原生的速度在浏览器中运行。它被设计为一种编译目标：你用另一种语言（Rust、C 或 C++）编写代码，把它编译成 WASM，结果就能在任何支持 WASM 运行时的环境中运行。无需安装，无需针对特定操作系统构建，处处行为一致。

这种可移植性正是它的吸引力所在。一个能在 Chrome、Firefox、服务器或边缘节点上运行的单一二进制文件，听起来正是容器化部署工作流所需要的。然而在实践中，“到处都能运行”和“能运行游戏服务器”之间的差距事实证明相当大。

尺寸优势：完整游戏引擎仅 35MB

这些数字值得好好想一想。一个完整的 3D 游戏引擎只有 35MB，而一个精简的 Python 基础镜像在你添加任何依赖之前就已经是 144MB，Node.js 最新版则是 421MB。再拿 Facebook 的首页作比较，它会加载 44MB 的资源。这个游戏引擎比这一切都要小。

这种体积差异在实际运维上很重要。更小的二进制意味着更快的游戏服务器冷启动（也就是镜像下载到服务器主机并启动一个游戏实例所需的时间）。对于自己运行编排系统的工作室来说，镜像分发的出站流量成本也是一个次要但仍需考虑的因素；不过在托管平台上，这部分成本通常由服务提供商吸收，而不是计入工作室账单。

对于那些已经自建内部编排系统的工作室，例如使用 Agones 的团队，冷启动时间和镜像仓库容量都是需要通过有意识的工程投入来解决的约束。在托管平台上，这些问题是按设计解决的：例如 Edgegap 的平台能在 平均 3 秒内从冷启动启动游戏服务器，并提供 10GB 的容器仓库。对出站流量如何影响其特定基础设施成本感到好奇的工作室，可以通过 Edgegap 的定价来了解它如何影响自己的部署，使用我们的 游戏服务器托管计算器即可。

正是这种效率上的论点，让 WASM 值得被认真看待为一种服务器技术。问题在于，二进制大小只是游戏服务器需求的一个维度。

服务器问题始于 WASI

要在浏览器之外运行，WebAssembly 需要一个与底层操作系统交互的接口。

这个接口就是 WASI：WebAssembly System Interface。WASI 让 WASM 二进制在服务器运行时而不是浏览器沙箱中运行时，能够访问文件、环境变量和标准 I/O。

问题在于 WASI 目前限制了什么。根据运行时和语言组合的不同，TCP 和 UDP 套接字要么不可用，要么受到严重限制。文件系统访问模型基于能力权限，并且被严格沙箱化。对于 Web API 或无服务器函数来说，这些限制是可以管理的；对于游戏服务器来说，它们就是阻碍。

多人游戏服务器运行在套接字之上。它们需要原始 UDP 来实现快速、低开销的数据包传输。它们也需要文件系统访问来进行配置、日志记录和状态持久化。

就 2026 年的现状而言，WASI 并不能在游戏服务器所需的层面上提供对这两者的可靠访问。正如 Bogomolov 在帖子里直言的那样：“wasip1 仍然只是预览版，标准运行时里没有 socket。”

语言支持的情况也让问题更加复杂：如今只有 Rust 和 C/C++ 是实际可行的 WASM 编译目标。Go 对 wasip1 的支持仍处于预览阶段。Zig 也还没到位。单这一条约束，就限制了哪些工作室甚至可以尝试构建 WASM 服务器。

没有线程的线程化

游戏服务器不是单线程程序。物理模拟、网络 I/O、游戏状态复制以及玩家输入处理通常是并发运行的。引擎本身就是围绕这一假设设计的。

WebAssembly 的线程支持很有限。现有机制需要在应用层做变通，通过中断和协作式调度来近似并发执行。其结果并不等同于真正的操作系统线程。它会引入协调开销，增加代码复杂度，并让高负载下的调试更困难。

即使某个工作室已经解决了 WASI 的套接字限制，在其游戏服务器能够大规模正确运行之前，仍然必须先处理线程问题。这些都不是微不足道的集成任务，而是当前 WASM 规范中的根本性架构缺口。

即便你解决了所有这些：WebSocket 之墙

假设某个团队投入工程努力，绕开 WASI 的套接字限制，并构建出一个能够承压的线程模型。

仍然还有一堵墙：WebSockets。

WASM 服务器运行时默认通过 WebSockets 通信。WebSockets 运行在 TCP 之上，在每条消息之上又增加了一个持久连接层，以及它自己的握手开销、分帧开销和安全协商开销。对于浏览器来说，这可以接受；对于游戏流量来说，这很昂贵。

游戏之所以使用 UDP 而不是 TCP，是有原因的。UDP 轻量且快速，没有握手，没有可靠投递的额外开销，也没有队首阻塞。晚到的数据包会被丢弃，这远比一个等待重传而卡住的连接要好得多。从延迟补偿到回滚，整个游戏网络代码领域都是围绕 UDP 的这些特性构建的。

如果改为通过 WebSockets 路由游戏流量，就会抹去 WASM 小二进制体积原本承诺带来的大部分性能优势。服务器最终要么把 CPU 周期花在 WebSocket 开销上，要么在规模化时遇到 DNS 解析问题，要么产生足以让部署在经济上难以成立的出站流量成本。

插件兼容性：隐藏的移植税

除了基础设施约束之外，还有一种工作室很少在前期计入的实际开发成本。大多数资源商店包、引擎插件和第三方 SDK 都不会自动编译成 WebAssembly。它们面向的是原生平台：Windows、Linux、macOS。

将它们移植过去需要手工工作。与基于 Docker 的部署相比，WASM 游戏开发的社区支持要薄得多。文档稀少，教程罕见，而边缘案例往往要等团队已经深入项目之后才会被发现。

对于严重依赖插件的工作室，或者没有深厚系统编程背景的团队，仅仅是移植负担本身，就足以让 WASM 服务器方案变得不切实际，而不论其理论上的效率收益如何。

WASM 现在真正适合哪里：单人 WebGL 游戏

有一个场景可以绕开上面所有限制：客户端单人网页游戏。

在浏览器中运行的单人游戏不需要原始 UDP 套接字，不需要操作系统级线程，也不需要与为原生目标构建的插件生态系统交互。浏览器提供了一个受控环境，在这里 WASM 的这些限制对使用场景根本无关紧要。

Godot 把这一点表现得很具体。该引擎针对其网页目标默认导出为 WebAssembly。一个单人 Godot 游戏会以 35MB 的二进制形式发布，并可在任何现代浏览器中零安装运行。对于 Linux 服务器部署，Godot 则会导出原生二进制。这个区别并非偶然：它准确反映了 WASM 当前能力上限所在的位置。

Rust 和 WebAssembly 生态系统讲述了类似的故事。最常被引用的 WASM 学习资源之一是 Rust 和 WebAssembly 官方书籍，它通过构建康威生命游戏来讲解一个基于浏览器的 WASM 项目。这是该技术发挥良好作用的经典例子。但它同样也是一个没有服务器端网络需求的单人、浏览器绑定应用。

WASM 对单人网页游戏来说确实合适。多人游戏后端则是完全不同的问题。

一个有判断的观点：采用曲线

至少在实验形式上，运行 WASM 作为服务器端技术的基础设施已经存在。Cloudflare Workers 在边缘运行 WASM 模块。containerd/runwasi 为 containerd 带来了 WASI 工作负载支持。KWasm 为 Kubernetes 节点增加了 WebAssembly 支持，尽管它的维护者目前仍建议不要在生产环境中使用。工具链正在被建设出来，而且很谨慎。

这一轨迹类似于 ARM 节点进入云基础设施讨论的过程。ARM 多年来在成本和密度方面都有真正优势，之后才成为云工作负载的默认选择。技术上的理由很早就已清楚。由于生态系统成熟度、工具链支持和组织惯性的原因，采用进度一直滞后。然后它就不再滞后了。

WASM 是否会在游戏服务器上走出同样的路径，需要明确说明，这是一种观点，而不是既成模式。当前的限制是具体且有据可查的。它们会如何改变、在什么时间线改变，则取决于浏览器厂商、运行时维护者和标准组织之间的决定。Bogomolov 在帖子结尾提出了同样开放的问题：“为什么 WASM 的采用停滞了？传输大小方面的理由已经存在。”

这是一个公平的问题。就游戏服务器而言，答案是二进制大小从来都不是唯一的问题。

今天你能做什么

在 2026 年，WASM 还不是一个可行的游戏服务器容器。对于部署专用多人服务器的工作室来说，Docker 仍然是实际可行的选择，而且围绕它的运维工具成熟、文档完善、支持广泛。

话虽如此，他的观察所引出的效率问题确实是真实存在的。服务器二进制大小对于冷启动性能和出站流量成本都很重要，而且工作室可以借助现有工具采取一些实用步骤。对于 Unreal Engine，Edgegap 已经发布了一份通过 服务器性能分析来分析和优化游戏服务器构建的指南。对于 Unity，服务器构建优化的指导则直接写在 Edgegap 的 文档中。

WASM 也许有一天会在体积方面带来的收益，如今就可以借助现有工具实现，而无需等待整个生态系统成熟。

—

本文参考了 Ivan Bogomolov 的原创帖子，该帖子发布于他的 个人博客。原始内容的所有权利归其各自所有者所有。