一台 Game Boy 模拟器，绕进浏览器跑了一圈，反而在 Pokémon Blue 基准里赢了原生解释器。

这就是 WATaBoy 有意思的地方。它没有直接把 Game Boy CPU 指令编译成本机机器码，而是在运行时把 SM83 指令编译成 WebAssembly 模块，再让浏览器的 Wasm 引擎把它变成机器码。

多走一步，却可能更快。真正值得看的也不是 Game Boy，而是平台规则：当 iOS 这类环境不让普通 App 做原生 JIT，浏览器里的 Wasm/JIT 例外，就成了模拟器性能的一条窄路。

WATaBoy 做了什么，快在哪里

WATaBoy 是一个概念验证项目。它的背景很明确：Dolphin 这类模拟器在 iOS 上长期受限，一个核心原因是普通 App 不能随便 JIT。

但浏览器不同。JavaScriptCore 和 Wasm 引擎为了 Web 性能，本来就会把代码编译成机器码。WATaBoy 的思路，就是把模拟器的动态编译需求塞进 Wasm 这条允许路径。

问题WATaBoy 的做法目前能说明什么
编译对象Game Boy 的 SM83 指令目标较小，适合做概念验证
执行路径SM83 → Wasm 模块 → 浏览器机器码借浏览器完成机器码执行
Pokémon Blue 基准JIT-to-Wasm 约比原生解释器快 1.2 倍只说明该测试条件下有效
对比 Wasm 解释器约快 1.5 倍JIT 路径确实吃到了红利
主要限制编译、实例化、链接、间接调用都有开销不能直接外推到所有 ROM、浏览器和设备

技术路径并不轻。

它要生成 Wasm 模块，再通过 JS embedder 编译、实例化、链接。函数还要挂到间接函数表里，用 call_indirect 执行。

一句话：Wasm 不是一块想写就写、想跳就跳的本机代码内存。它必须让浏览器这个宿主开门。

门能开，但规矩不少。

关键变量不是 Game Boy，是浏览器这张通行证

Game Boy 本身不是最需要 JIT 的平台。现代设备上，一个写得不错的解释器已经能跑得很稳。

所以这个结果不能读成“浏览器模拟器全面胜利”。更准确的读法是：在不方便自己生成机器码的平台上，开发者能不能把动态编译改写成 Wasm 生成，再交给浏览器完成后半程。

这对两类人最直接。

模拟器开发者会多一个实验方向。尤其是想在 iOS、浏览器或受限平台上做高性能模拟器的人，可以把 JIT-to-Wasm 当作候选路线，而不是只在解释器和原生 JIT 之间二选一。

独立开发团队则要更谨慎。它不是“把核心搬到 Wasm 就完事”。你得评估模块生成成本、缓存策略、块边界、中断、MMIO、回退解释器，以及不同浏览器的 Wasm 编译行为。

这里最容易误判的是性能账。

Pokémon Blue 的 1.2 倍很漂亮，但它不是通用结论。ROM 行为、浏览器实现、设备性能、热代码形态，都会改结果。换到更重的主机，编译和调度成本可能迅速放大。

这也是为什么我不把它看成 Dolphin 级模拟器已经有了 iOS 落地方案。WATaBoy 目前更像一个清楚的路标：路在这里，但还没证明能跑重车。

这次漂亮，但账还没结完

我更在意的是平台规则，而不是单个 benchmark。

苹果限制普通 App JIT，有安全、审核和平台控制的因素。浏览器保留 JIT，则是现代 Web 性能的底盘。WATaBoy 正好站在这两条规则的交界处。

它没有真正“绕过苹果规则”。它依赖的是浏览器和 WebKit 允许的 Wasm/JIT 执行路径。说白了，不是翻墙，是走了一扇本来就开着、但只给特定身份开的门。

这让我想到早期 Web 对桌面软件分发边界的冲击。不完全一样，但结构很像：平台画线，开发者找缝；规则收紧，工程绕行。

“天下熙熙，皆为利来。”这里的利不是口袋里的钱，至少不只是钱。它是性能，是分发自由，也是开发者不想被平台能力表锁死的那点空间。

接下来真正该看四件事。

观察点为什么重要
不同浏览器下是否稳定变快Wasm 编译器差异会直接改变结果
更多 ROM 是否复现收益Pokémon Blue 不能代表所有负载
编译与实例化成本能否摊平启动、切块、缓存都会吃掉优势
更复杂模拟器能否承受工程复杂度Game Boy 成功不等于高世代主机可用

如果这些条件站不住，JIT-to-Wasm 就只能停在漂亮 demo。能跑，是第一关；能稳定赢，才是产品路线。

我的判断很简单：WATaBoy 做对了一个工程问题，但它没有消灭平台问题。它只是证明，在平台留下的缝里，开发者还能把性能挤出来一点。

这已经很有价值。只是别把窄路看成高速路。