为什么搞懂版本演进，比写对第一行代码更重要

先讲个真实的故事。2019 年前后，有个独立开发者用 Unity WebGL 把一个很有想法的 3D 小游戏发到了浏览器。本地编辑器里丝滑得很，导出构建一跑，载入四十秒，进去帧率二十五。他以为是自己的美术资源太肥，疯狂压图、减面、砍粒子，折腾了两礼拜，最后在论坛帖子里才弄明白——这事跟他代码写得好不好没关系，他撞上的是 WebAssembly 当时那套功能集的天花板。

说句实话，我自己也翻过类似的跟头。那会儿我默认觉得“标准都发布了，功能应该就有了吧”，结果一查，某个我离不开的能力在提案阶段是 Phase 3，在浏览器实现里是半开半关，在游戏引擎的构建选项里还被藏在一个叫“Experimental”的复选框后面，旁边写着“可能导致不可预期的行为”。你猜怎么着？它真的导致了不可预期的行为。

WebAssembly 不是一个一次性砸下来的标准。它更像是一份每年都在修订的菜单：有些菜开张就有，有些得等好几年，还有些菜厨房说“下周就上”，结果你等了两年。游戏开发恰好是那种对菜单极其敏感的行当——物理步进、渲染批量、资源加载、脚本逻辑，每一块都能精确对应到某个具体的 Wasm 特性上。你要是不知道哪道菜哪年上桌，架构设计上就可能一脚踩空。

这篇文章想干的事很朴素：把从 MVP 到 WASM 2.0 这条路上的每一段岔口，按时间、按特性、按它对游戏意味着什么，撕开给你看清楚。上一篇我们聊了 asm.js 到 Wasm 那场十年战争，那是“从没有到有”；这篇聊的是“有了之后，逐年加装了什么”。下一站才是 WASI 带它出浏览器那一步。地基都在这一篇里。

第一层：MVP——能跑起来了，但游戏跑得憋屈

2017 年，WebAssembly 的 MVP（Minimum Viable Product，最小可行版本）在主流浏览器里同时点亮。这是件了不起的事，也是件很克制的事。设计团队当时做了一个挺大胆的决定：先把最核心的部分推出来，剩下的靠后续提案慢慢加。好处是浏览器厂商能快速统一落地，坏处是早期上来的游戏开发者基本是在用一副骨架搭房子。

MVP 给了你什么？一大块线性内存，整数和浮点的基础运算，基础控制流（分支、循环），函数导入导出，以及一个挺靠谱的沙箱安全模型。对游戏来说，这已经能把 C/C++ 写的物理、碰撞、寻路全部搬进浏览器了。别小看这件事，这在 asm.js 时代是不可能这么干净的。

但它缺的东西，恰好是游戏最敏感的那几块。

你试着想象这样一个场景：你在做一款有实时布料模拟的游戏，每一帧要对上千个顶点做位置计算。MVP 时代，每一个顶点运算你只能老老实实地用标量指令跑一遍，一次算一个数。SIMD 一个指令能并行算四个。也就是说，同样是那一帧的预算，你能做的事情被硬生生砍到了四分之一。这不是你优化能不能救回来的问题，这是“这个玩法今天能不能做”的问题。

那个年代上线的 WebAssembly 游戏，大多有一个共同特征：可以玩，但玩法被迫简化，或者美术被迫减配，或者游戏帧率被压在 30 以下。这不是团队不努力，是当时的地基就这个高度。谁要是跟你说“我 2018 年在浏览器里跑 3A 级画面”，你要么遇上的是个天才，要么他记错年份了。

这里插一句我的偏见：我特别不建议独立开发者一上来就假设“标准发布=能力可用”。这两件事之间隔着一整条产业链，从提案、参考实现、到浏览器上车、再到引擎工具链默认打开，每一环都能卡几个月到几年。你真正能依赖的，永远是“我的目标环境里这个功能已经默认开着且稳定”。

第二层：批量扩展的几年——把游戏最缺的几个器官补齐

2018 到 2021 这几年，Wasm 走的是一条“批量补器官”的路。这个阶段没有什么革命性的范式变化，但补进来的每个特性都直接对应到游戏里一个具体的痛处。我把它们分成两组来讲，一组管“算得快”，一组管“连得顺”。

算得快那一组

多值返回大概 2020 年前后在主流浏览器里稳定下来。听起来是个很技术的改动，实际体验差别巨大。举个具体场景：你要算一个三维向量的归一化，MVP 时代这个函数只能返回一个值，想把 x、y、z 一起带回来，要么拆成三次调用，要么干脆写回内存再读。多值返回之后，一次函数调用把三个结果拍在一起交给你。对于一个物理引擎里被调用几十万次的数学库来说，这种“每次少几跳”的节省会累积成实打实的一帧时间。

SIMD 大概是 2021 年前后大范围落地，提供 128 位向量指令。对游戏开发者，这是血脉级的能力。角色骨骼动画、粒子发射、布料模拟、射线求交、矩阵批量变换，这些工作有一个共同特点：同样的算式，套在成堆的数据上跑。SIMD 让你一次处理四个浮点数、八个半精度浮点数、或者十六个字节。

我印象很深的对比案例是物理引擎。一个典型 2D 刚体世界里，每帧要遍历所有接触点、算一遍法向和切向冲量。这套计算写成标量代码是能跑，但一旦 SIMD 上马，光是法向约束这块就能明显提速，具体倍数取决于代码写得有多“向量友好”。社区里常见的说法是 1.5 到 3 倍之间，实际能跑多少，全看你有没有把数据结构重排成“连续四个一起算”的布局。这对独立游戏团队的意义不是“性能更好”，而是“这个玩法到底敢不敢做”。

尾调用来得相对晚一点。它解决的是“函数套函数、但没有栈开销”的问题，对状态机、AI 行为树、场景脚本解释器这类结构是刚需。你要是做过游戏里的剧情脚本系统，就知道那种“解释器递归执行节点”的代码一旦没有尾调用，稍微深一点就爆栈。有了尾调用之后，整个解释器的深度问题直接消失。

连得顺那一组

引用类型（externref 那套机制）解决的是 JS 和 Wasm 互相递对象的难题。MVP 时代，你要把一个 JS 侧的音频对象交给 Wasm 里的混音器，只能给它发一个整数 ID，然后在 Wasm 里再维护一张表把 ID 映射回对象，来回查表，聊得特别累。引用类型引入后，JS 侧的对象可以直接被 Wasm 函数接住，虽然不能在里面随便读写，但传递就是传递，干干净净。

批量内存操作（bulk memory，大致是原生 memory.copy、memory.fill 这一套）看起来像小修小补，实际对游戏很实用。地图分块加载、纹理数据拷贝、实例化顶点缓冲填充，全都在大量使用内存块复制。以前这些操作得用循环一个一个字节地抄，现在是一条指令搞定，速度和你手写的“最优循环”比也不会差，甚至更稳。

这一层的真实感受，我可以用一个很具体的方式给你——一个 2017 年移植的游戏和一个 2022 年移植的同一个游戏，站在玩家视角是完全两个游戏。 前者你得忍受进入关卡前那段 Loading 转圈、跑动时偶尔卡一下、场景复杂点就掉帧；后者这些问题大部分不见了，但你说不出是哪一件事改进了它。改进就是这样一点点攒出来的。

这里我必须举个真实拆解案例，不然全是概念太虚。

案例一：Godot 4 的网页导出，一场关于“线程依赖”的硬仗。

Godot 4 在浏览器里跑的时候，架构上高度依赖多线程。主线程负责和浏览器的 WebGL、DOM、输入事件打交道，物理世界、渲染命令收集、脚本逻辑分散在各自的 Worker 里跑。这套结构如果放在桌面，是标准做法；放到浏览器里，就一脚踩进了 Wasm 线程提案和它的伴生兄弟 SharedArrayBuffer 的坑里。

SharedArrayBuffer 是什么？简单说是一块能被多个线程同时读写的内存。它本来是浏览器里很普通的能力，后来因为安全漏洞（Spectre 那一类）被各大浏览器默认关掉了，重新打开的条件是：网站必须启用跨域隔离，也就是服务器返回 Cross-Origin-Opener-Policy 和 Cross-Origin-Embedder-Policy 两个响应头，把页面和外部资源严格隔离。

这件事对独立开发者的实际后果是什么？你在本地开发时，自己搭的服务器往往已经配好了这两个头，游戏跑起来很快。游戏一传到某些托管平台、博客静态站、或者某些不太灵活的发布通道，这两个头不一定给你加。你猜怎么着？玩家点开你的页面，看到的是黑屏，或者一行报错“SharedArrayBuffer is not available”。

这个坑不是 Godot 设计错了，也不是玩家浏览器太老——这是 Wasm 规范演进加浏览器安全策略共同搭出来的地形。一个引擎在 2017 年想做这套架构，因为 Wasm 线程还没到位，只能退回到单线程或自己实现软件调度，性能会惨很多。等到 2021 年前后线程可用，Godot 才能这么设计，但设计完之后，部署门槛也跟着上来了。

你如果是做独立游戏的，从这个案例里要带走的信息很明确：特性可用性和部署可用性，是两件事。 前者是技术问题，后者是产品问题。两者合一的时候，你的游戏才算真的能交给玩家。

案例二：Ruffle 的追赶，一段被规范化节奏切开的玩家体验。

Ruffle 是一个用 Rust 写、编译成 WebAssembly、在浏览器里重放老 Flash 内容的开源项目。它最核心的用途，就是让 Newgrounds 时代那批 Flash 小游戏能在今天还能打开、还能玩。这件事看起来挺情怀，技术上却极其硬它——Flash 是个实时性极强的东西，玩家节奏稍微一卡，原本精心设计的操作手感就废了。

Ruffle 这几年一直被玩家拿放大镜看着。早期版本的用户评价里，“卡”“慢”“还不如装 Flash 插件”是高频词。随着项目推进，一批批不同年代、不同复杂度的 Flash 游戏被逐个跑通，帧率慢慢追上原生 Flash。这个过程里，Wasm 自身的特性演进起了很实际的提速作用——函数调用开销变低、SIMD 让图形栅格化更快、内存访问模式更顺，这些技术层面的东西最终叠加成玩家手里那个“总算跟当年差不多了”的体验。

我觉得 Ruffle 最值得讲的一点，是它的性能曲线被规范化节奏切成了好几个阶段。Phase 之前的一版能跑 2D 交互游戏但动作迟钝，Phase 之后的一版能跑更复杂的动画和 AS3 逻辑。玩家感受不到“Wasm 提案进入 Phase 4 了”这种新闻，但玩家能感受到“这一版我的跳跃终于不歪了”。规范演进的真实影响，从来都是藏在两版之间玩家的沉默里的。

第三层：WASM 2.0——第一次给游戏开发者一份能指着说话的稳定清单

2022 年前后，W3C 把已经稳定的一大批提案打包，形成了 WebAssembly 2.0 这一版规范快照。这一步的意义不在于“性能突然又涨了”，因为这个版本里几乎所有的特性，早就在各个浏览器引擎里单独上线过了。它的意义在于——第一次有了一份可以指着说话的稳定基线。

2.0 里进笼的，集中在前两层我们聊过的东西：多值返回、引用类型、批量内存操作、SIMD、尾调用等等。打包在一起之后，对游戏开发者来说最实际的变化其实在沟通上。你可以在项目技术文档里写一句“本项目基线按 WebAssembly 2.0 设计”，引擎团队、外包合作方、发布渠道方，看到这句话就知道该准备什么工具链、哪些老坑不用再踩、哪些能力不用每次都测一遍。

跨版本的工具链挑战，在 2.0 之后一下小了很多。以前你要选 Emscripten 还是 Rust 编译链，一家一家测哪个版本开了哪个特性，不稳定的时候还得写开关。2.0 这种打包规范出来之后，主流工具链很快就统一了默认目标。你更新编译器版本，不会莫名其妙打开或关上某个你依赖的能力。这种“少操心”是最被低估的开发体验升级。

我个人的观点是，Wasm 2.0 真正的里程碑意义在于它给了游戏团队一个信号：阶段性舔完伤口、可以往下一个大方向看了。 之后所有重量级的提案——GC、异常处理、Component Model、Memory64——全都站在 2.0 的肩膀上。你如果现在开始规划一款两三年后要发布的浏览器游戏，2.0 就是你非常安全的那把椅子。你要押注的应该是：2.0 之后哪个提案会在你上线之前稳下来。

第四层：提案追踪——怎么提前押注、少踩空

到了这一层，就是给那些准备押注未来的团队看的了。Wasm 的提案流程有一套比较固定的阶段划分，我按游戏开发视角给你简单过一遍。

工具层面上，我一般让团队盯三处。第一处是 GitHub 上 WebAssembly 官方仓库里每个提案的目录，里面有完整状态和讨论细节。第二处是 W3C 社区组的公开会议纪要，那里面能听出哪些厂商正在推、哪些正在拖。第三处就是 MDN 和 caniuse 这类兼容性数据库，用来确认“这个功能在我要发布的那几个浏览器里到底开没开”。

别小看这三处的组合价值。我见过不止一个团队，光看提案已经到 Phase 4 就以为可以用了，结果实际一测，某个目标浏览器的新版本还没上，或者上了但默认是关闭的。还有更隐蔽的，功能开了，但性能还不行——早期实现往往没有优化，它确实能用，但慢得让你怀疑人生。

社区参与这件事，很多独立开发者觉得离自己很远。其实不太远。提案的 GitHub Issue 里，你能提用例、能抱怨 API 设计、能举报 bug。这些声音不算“大厂话语权”的重量，但一个真实的游戏开发者用例往往会让维护者认真考虑。如果你押注某个提案，而且在上面踩了坑，你到那个 Issue 里把它写清楚，一来别人少踩，二来厂商多一份证据——这不虚。

参数化对照：不同游戏类型对规范版本的依赖表

我不太喜欢给读者一张“技术清单表”就完事。技术清单是给工程看的，游戏团队真正想看的其实是“我这个游戏要什么、最小版本是什么”。我把常见类型拆成三张表，每张给不同侧面。

表一：游戏类型 × 特性依赖强度

表二：常见特性的建议使用门槛（按我的实战经验）

表三：技术验证清单（每三个月核一次就行）

说句实话，最后那张表里最后一行，是最容易被跳过也是最不该跳过的。别人家博客里写“SIMD 提速 3 倍”，跑到你自家游戏里可能是 1.2 倍，因为你根本没做向量友好的数据布局。基准测试这件事，“在你自己那个场景里测一遍”永远比其他地方的任何数字有用。

两种读法：你只是想上线，还是想押注未来

初级用户读到这里可以停一下，先问自己一句话：我的游戏到底用不用得上 2.0 之后的东西？

答案很多时候比你想象的简单。如果你做的是休闲、卡牌、文字、点击类、管理模拟——《吸血鬼幸存者》那种满屏弹幕但逻辑简单、靠数量堆感受的——说实话，MVP 时代的能力就够用，你不需要 SIMD 帮你算四个向量，你也不需要线程把载入切成八段。你真正要做的，是选一个已经把这些坑填好的引擎（Godot、Unity 或者某个 Rust 框架），直接按人家的默认配置来。别在特性表里找优越感，你找的是发布那天不黑屏。

如果你做的是 3D、物理密集、开放世界、AI 角色多、或者有比较讲究的多人逻辑——那建议你把基线定成 WASM 2.0，然后把“线程和 SharedArrayBuffer 能不能用”当成产品需求来对待，不是技术细节。这件事要提前跟发布渠道确认，别等到快上线了才发现某个平台不肯给你发那两个响应头。

中级用户往这边看：真正的竞争力在“节奏感”上。

我的建议是做一份半年一更的“Wasam 特性预测表”。列出你未来 24 个月可能想要的特性（比如异常处理、GC、Memory64），给每个标上：当前阶段、我目标浏览器的最新状态、我的引擎支持状态、我上线时间窗里它能不能全绿。三个都能对上的，可以考虑排进开发计划；有一个不确定的，扔进“实验分支”；全都对不上的，先不碰。这套东西看起来像项目管理，但它给你省下的返工时间，比任何优化技巧都值钱。

另外还有一个容易被忽略的点：不要只看阶段，要看阶段之后的“缓冲期”。 一个提案进入 Phase 4 到它真的在浏览器里稳定、性能靠谱、工具链默认开，往往还要一两年。这段缓冲期不是一个 bug，是生态的现实。你如果非要按 Phase 4 的时间表排期，大概是会撞墙的。

几个真被踩过的坑，别当别人故事听

还有一层争议挺有意思：“WASM 2.0 之后，游戏团队到底该押哪个提案？” 我个人的判断是，游戏主循环最关心的有两个方向——GC 提案让托管语言的原生化变得可行，对用 Unity、Godot、或者想用 C# / Dart 的团队影响深远；异常处理提案让错误处理真正回到“语言原生”的体验，对大型项目的代码质量收益不小。但两者都不是“今晚上线就要”的东西，它们更像下一阶段的地基。你要押注可以，但别让它挡了你现在手里的那款游戏的发布节奏。记住一句话：做游戏的人，最重要的能力是决定什么不做。

FAQ：几个被问得最多的真问题

Q1：MVP 现在还能用吗？会不会迟早被迫升级？

能。MVP 的能力集今天所有主流浏览器依然支持，而且支持得很稳。你如果做的是简单 2D 游戏，压根没必要追新特性。会不会被迫升级？只要你引擎选得对、不追求最新玩法，基本不会。真正逼你升级的是“我想做的游戏必须要新特性”，不是“规范更新了”。分清楚这两件事，能省掉一堆焦虑。

Q2：WASM 2.0 是终点吗？后面还有没有 3.0？

不是终点，也大概率不会是一个“3.0 一把梭”的方式。更可能的路径是持续打包阶段性稳定提案，形成新版本快照。你不需要等一个 3.0 官宣，你要看的是“下一个稳定快照里可能包含哪些我关心的提案”。追踪方法就是前面说的那三处工具。

Q3：尾调用对游戏到底有没有实际影响？我怎么知道自己需不需要？

有一个很简单的自测：你的游戏里有没有解释器、状态机、或者行为树？有的话，大概需要。没有的话，大概率不用管。尾调用最核心的价值是“深层递归不爆栈”，游戏里最常见的需求点就是各种“节点解释执行”的系统。你平时写游戏逻辑基本用不到它，但你一旦写引擎级代码，它很容易出现在你的需求表里。

Q4：GC 提案和异常处理提案落地对我这个用 Unity / Godot 的人有什么影响？

影响是间接的，但确实有。这两个提案直接决定“托管语言写不写得了原生 Wasm”。像 Unity 的 C#、Godot 的 C# / GDScript，如果未来要减少对桥接层的依赖、追求更原生的性能，这两个提案是关键路径。你现在不用为它改代码，但你可以在引擎版本演进时留意——未来某个大版本可能因为这两个提案落地而变快、变小、变干净。

Q5：如果我用的就是某个引擎的网页导出，还需要自己关心规范版本吗？

需要，但只关心“边界”那部分。具体指的是：你的引擎当前构建依赖哪个 Wasm 版本基线、你有没有主动开启某个实验特性、你的部署环境能不能满足它。剩下的具体提案细节交给引擎团队。你要盯的是“部署那天到底能不能跑起来”，这件事永远是你自己的责任，只是好引擎帮你把前半段包圆了。

Q6：有没有一句能带走的话？

有。 标准负责喊口号，浏览器负责兑现，工具链负责把它变成你能用的按钮，玩家只负责一件事——游戏点开能不能玩。 你能掌控的只有最后一环，所以永远把验证放在最后一环去做。别信任何一版的豪言壮语，信你自己那台机器上跑出来的结果。