复古游戏模拟器从本地应用程序向 Web 平台的迁移，代表着软件架构层面的一次重要范式转变。传统模拟器通常以原生代码形式运行，直接与操作系统底层交互以获取硬件资源；而 EmulatorJS 则选择了一条不同的技术路径 —— 它并非从零编写模拟器核心，而是充当 RetroArch 在浏览器环境中的前端界面，通过加载预编译的 libretro 核心（编译为 WebAssembly 格式）来执行游戏模拟。这种设计使得开发者无需为每个游戏平台重复实现底层模拟逻辑，只需维护一套统一的 JavaScript 前端框架，即可对接数量庞大的 libretro 核心生态。从工程角度看，这种分层架构将模拟器的复杂性封装在跨平台的二进制核心中，而将用户界面、交互逻辑和平台适配工作留给 JavaScript 层处理，从而实现了关注点的有效分离。
EmulatorJS 的技术栈核心由三层组成：最上层是 JavaScript 构建的响应式用户界面，提供游戏列表管理、模拟器配置、存档管理和多语言支持等功能；中间层是轻量级的胶水代码，负责在前端框架与 libretro 核心之间传递输入事件、视频帧和音频数据；最底层则是通过 Emscripten 交叉编译得到的 WebAssembly 核心文件，每个核心对应一个游戏平台（如 NES、SNES、PS1、N64 等）。这种分层设计的关键优势在于，当某个模拟器核心需要更新或修复时，只需替换对应的 .wasm 文件即可，前端代码无需任何改动。反之，如果需要调整用户界面的视觉风格或交互逻辑，也完全不会影响到核心的模拟行为。这种松耦合的架构思想来源于 libretro 项目的设计理念 —— 核心（core）与前端（frontend）的职责边界被清晰定义，核心只负责执行模拟逻辑并通过标准回调接口输出多媒体数据，而前端则负责处理所有与用户交互和平台相关的细节。
在 WebAssembly 编译层面，libretro 核心的迁移过程涉及若干关键技术决策。标准的 libretro 核心原本是为本地操作系统设计的 C 语言程序，它们依赖系统调用获取图形渲染上下文、音频缓冲和输入设备状态。EmulatorJS 的解决方案是利用 Emscripten 工具链，将这些依赖系统特定 API 的代码转换为浏览器兼容的 WebAssembly 和 JavaScript 填充代码（polyfill）。具体而言，核心在初始化时会调用 retro_set_video_refresh、retro_set_audio_sample 和 retro_set_input_state 等回调函数，将渲染任务交由前端处理；前端则在 WebGL 或 Canvas 2D 上下文中绘制视频帧，通过 Web Audio API 播放音频样本，并在键盘、鼠标或手柄事件触发时将输入状态回传给核心。这种架构使得同一份核心二进制文件可以在任何支持 WebAssembly 的浏览器中运行，而无需针对不同浏览器进行重新编译。值得注意的是，编译过程中需要对内存布局和指针类型进行仔细处理，因为 WebAssembly 的线性内存模型与本地进程的地址空间存在本质差异。
从性能角度审视，WebAssembly 模拟器面临着与原生应用不同的约束条件。浏览器环境的沙箱特性意味着模拟器无法直接访问物理内存或底层硬件，所有资源分配都必须通过 JavaScript 运行时进行协调。EmulatorJS 在处理这一问题时采用了按需加载策略：核心文件和游戏 ROM 在首次运行时异步获取并缓存在 IndexedDB 中，避免阻塞用户界面；对于内存占用较大的核心（如 N64 或 PSP 模拟器），框架会在加载前向用户显示预估的内存需求，并在内存压力过高时触发垃圾回收或提示用户关闭其他标签页。在渲染管线方面，框架优先使用 WebGL 进行视频输出，因为 WebGL 能够利用 GPU 加速纹理绘制和像素格式转换，这对于需要以每秒 60 帧稳定运行的游戏尤为重要。对于不支持 WebGL 的环境，框架会回退到 Canvas 2D 渲染模式，但性能会有所下降。输入延迟是另一个需要关注的指标，EmulatorJS 通过在事件循环的早期阶段处理键盘和手柄输入，并将输入状态直接写入共享内存缓冲区，尽可能减少了从用户操作到游戏响应的端到端延迟。
部署一个基于 EmulatorJS 的模拟器网站需要考虑多个工程维度。首先是核心选择问题 ——libretro 项目维护着超过 100 个核心，但并非所有核心都完成了 WebAssembly 编译，或在浏览器环境中表现稳定。根据官方文档的建议，fceumm（NES）、snes9x（SNES）、gambatte（Game Boy）、mgba（GBA）和 pcsx_rearmed（PS1）等核心经过了大量测试，适合作为生产环境的选择；而一些需要高精度时序或特殊硬件特性的核心（如 3DS 的 Citra）在浏览器中可能存在兼容性问题。其次是文件托管策略，游戏 ROM 和核心文件通常体积较大，建议使用支持 HTTP Range 请求的静态文件服务器，并配置适当的缓存策略以减少重复下载。再次是法律合规问题，模拟器框架本身是合法的，但某些 BIOS 文件和游戏 ROM 可能涉及版权争议，部署者需要确保只提供合法授权的内容或引导用户自行获取版权材料。框架内置的多语言支持系统允许通过社区贡献的翻译文件轻松扩展语言覆盖，这对于面向国际用户的项目尤为重要。
与本周报道的 PS2 静态重编译项目相比，EmulatorJS 代表了另一种模拟器实现思路。PS2 静态重编译专注于将 MIPS R5900 指令集一次性翻译为本地机器码，追求极致的运行效率；而 EmulatorJS 则采用了解释执行与即时编译相结合的 WebAssembly 运行时模型，强调跨平台兼容性和部署便利性。从技术成熟度看，libretro 核心经过二十余年的迭代优化，在兼容性和准确性方面积累了深厚的技术债务；而 EmulatorJS 通过复用这套成熟的核心生态，避免了重新实现所有模拟器的巨大工作量。从应用场景看，PS2 静态重编译更适合需要高性能模拟的本地应用场景，而 EmulatorJS 则天然适合作为嵌入式组件集成到网页、游戏博物馆或在线教育平台中。两种技术路线并非相互替代关系，而是针对不同需求场景的合理选择。
资料来源：EmulatorJS 官方文档（emulatorjs.org）、Libretro 开发文档（docs.libretro.com）、EmulatorJS GitHub 仓库（github.com/EmulatorJS/EmulatorJS）。