你正在用 Chrome 浏览这篇文章。但在 Chrome 的一个标签页里，还有一个完整的 Firefox 浏览器在运行。它不是在远程桌面上，不是用 iframe 嵌入的，而是真正的 Firefox。Gecko 渲染引擎、SpiderMonkey JavaScript 引擎、地址栏、设置页面、关于窗口，全部被编译成了 WebAssembly，运行在另一个浏览器的沙盒里。这不是科幻片。这是 2026 年 7 月 16 日，Puter Labs 正式发布的「Firefox in WebAssembly」，一个在浏览器里跑浏览器的技术奇观。
浏览器里的完整浏览器
Puter 是一个开源的云端桌面平台，其核心愿景是在浏览器里提供一个完整的 PC 桌面环境。而 Firefox in WebAssembly 是这个愿景最激进的一次落地。项目页面位于 developer.puter.com/labs/firefox-wasm，源代码完全开源在 GitHub（HeyPuter/firefox-wasm）。用户打开页面，等待几十秒的加载后，一个完整的 Firefox 界面就会出现在当前浏览器的 Canvas 画布上。你可以正常输入网址、浏览网页、查看页面源码、打开开发者工具，甚至在里面再跑一个 WebAssembly 版的 Firefox。项目团队证实，他们确实成功实现了这种递归嵌套，在 Firefox 内部的 Firefox 里再启动了一个 Firefox，只不过只成功跑了一次。
这不是一个「长得像 Firefox」的 UI 壳。Puter 团队将 Firefox 的底层渲染引擎 Gecko 完整编译到了 WebAssembly 中。这意味着，你在其中看到的每一个网页，都是 Gecko 渲染的，而不是宿主浏览器渲染的。JavaScript 的执行也由 SpiderMonkey（Firefox 的 JS 引擎）的 WASM 版本来完成。为了减轻渲染压力，项目还启用了 GPU 加速，通过 WebGL 来分担图形渲染负载。
知名技术博主 Simon Willison 第一时间做了验证。他打开自己的博客，页面在 Firefox-in-WASM 中正常渲染，而 Chrome 的开发者工具显示，所有网络流量都通过 WebSocket 协议传输。他检查了加密情况：HTTPS 流量经过端到端加密，HTTP 流量则是明文，确认了 Puter 团队声称的端到端加密属实。他的结论很直接：「This is absurdly cool。」
烧了 2.5 万美元的 AI 辅助移植
将 Firefox 编译到 WebAssembly 不是一件简单的事。Firefox 的代码库有数千万行，横跨 C++、Rust、JavaScript 等多种语言，依赖大量的操作系统底层 API，包括文件系统、网络、线程、GPU 等。而 WebAssembly 运行在浏览器的沙盒里，这些底层 API 默认都不存在。
Puter 团队选择了 Emscripten 工具链，一个将 C 和 C++ 编译到 WebAssembly 的成熟方案。但即便如此，适配工作量仍然巨大。他们仅用几天时间就让 Firefox 在 WASM 中成功启动，但后续的性能优化和稳定性修复花了大量精力。
最引人注目的是开发成本。据 Puter 团队披露，整个项目消耗了约 300 亿个 AI 模型 tokens，折合超过 25,000 美元（约 400 万日元）。这笔费用全部花在了 Claude Opus 和 Claude Fable 的 API 调用上。他们利用 Anthropic 的 Claude Max 订阅计划，让 AI 辅助完成 JIT 编译器的研发、Bug 调查和代码优化。这个项目的核心开发工具本身就是 AI。没有 AI 辅助编码，一个团队要在合理时间内把 Firefox 搬进浏览器几乎不可能。
为什么是 Firefox，不是 Chromium
一个自然的问题：为什么不选 Chromium？毕竟 Chromium 是当前浏览器市场的绝对主导者，据 2026 年数据，基于 Chromium 的 Blink 引擎占据了全球 78.4% 的会话份额。
Puter 团队给出的答案很直接：Firefox 有更成熟的单进程运行模式。Chromium 的多进程架构虽然有利于稳定性，但每个标签页和每个插件都运行在独立的进程中，这给移植到 WebAssembly 带来了巨大挑战。而 Firefox 在单进程模式下运行的经验更丰富，移植起来更容易。
这本身就是一个有趣的讽刺。在浏览器市场节节败退的 Firefox，Gecko 引擎份额已降至 2.6%，反而因为其架构上的「老派」特性，成为了这个最前沿技术实验的最佳载体。当一个浏览器在市场上输掉了几乎一切，它却以另一种方式完成了穿越。
网络难题：Wisp 协议与代理架构
浏览器中的 WebAssembly 代码无法直接打开 TCP 套接字，这是出于安全考虑的硬性限制。运行在 WASM 中的 Firefox 如何访问互联网？
Puter 的解决方案是 Wisp 协议。这个协议将多个 TCP 和 UDP 连接复用到一个 WebSocket 连接中，通过 Puter 运营的中继服务器转发流量。当 Firefox-in-WASM 发起网络请求时，数据通过 WebSocket 发送到 Wisp 服务器，再由该服务器代为实现真正的 TCP 连接。外部网站看到的访问 IP 是 Puter 服务器的 IP（位于美国加州），而非用户的真实 IP。这也意味着 Puter 的服务器需要承担大量的流量转发。项目在 Hacker News 上走红后，团队不得不紧急扩容服务器来应对暴涨的流量。
项目还包含一个正在研发中的 JS 到 WASM 的 JIT 编译器。传统上，JavaScript 在浏览器中的执行由宿主浏览器的 JS 引擎完成。但在 Firefox-in-WASM 中运行含有 JavaScript 的页面时，会由 SpiderMonkey 的 WASM 版本来执行。这个 JIT 编译器试图将 JavaScript 代码实时编译成 WebAssembly 字节码，从而获得更快的执行速度。不过，项目团队坦承，这个 JIT 目前在大多数网站上还不可用，仍然处于实验阶段。
不止是炫技：Puter 的浏览器虚拟化矩阵
除了全量编译 Firefox，Puter 还开发了另一个名为 Browser.js 的独立项目。这是一个更轻量级的浏览器中的浏览器，内存占用更小，适合用于云浏览器和网站的自动化测试场景。这表明 Puter 的野心不止于技术炫技，而是在构建一个完整的浏览器虚拟化产品矩阵。
WebAssembly 自 2017 年 3 月首次在浏览器中落地以来，已经走过了近十年。它最初被定位为高性能 Web 应用的加速器。Figma 用 WASM 驱动设计工具，Unity 用 WASM 做网页游戏，Google Earth 用 WASM 在浏览器中渲染 3D 地球。但所有这些应用，都是以「应用」的形态运行在「浏览器」这个平台上。
Firefox in WebAssembly 打破了这层窗户纸。它不是在浏览器里跑一个应用，而是在浏览器里跑一个浏览器。一个完整的、能独立渲染网页、执行 JavaScript、管理 Cookie、处理 HTTPS 的操作系统级应用。这意味着，浏览器本身正在成为一个元操作系统（meta-OS），可以虚拟化任何软件，甚至包括它自己。
谁会需要这个？
在实用层面，Firefox in WebAssembly 的短期价值可能体现在几个方向。首先是云浏览器服务：在云端提供一个完整的浏览器实例，用户通过任意设备访问，无需本地安装。Puter 本身就是做这个的，Firefox-in-WASM 是它的技术能力上限演示。其次是安全隔离与测试：在沙盒中运行完整的浏览器，用于安全测试、网页兼容性测试、自动化爬虫等场景，Browser.js 项目已经瞄准了这个方向。最后是跨平台兼容：在基于 Chromium 的浏览器中运行 Firefox，可以测试网站在不同渲染引擎下的表现，这对于 Web 开发者来说是一个宝贵的工具。
但最大的问题不是技术可行性，而是经济可行性。每条网络请求都需要经过 Puter 的 Wisp 代理服务器，这意味着带宽成本可能是普通浏览的 2 到 3 倍。更不用说加载一个完整的 Firefox 需要几十秒的初始化时间，内存占用也远高于普通网页。用 25,000 美元的 AI tokens 才开发出来的 JIT 编译器，目前大部分场景还跑不了。
然而，每个新技术在诞生之初都面临类似的问题。1995 年的 Java Applet 被嘲笑太慢，2008 年的 Chrome V8 引擎被指责太吃内存。今天，WebAssembly 的性能瓶颈正在被逐步突破。Wasm GC、多线程、异常处理等新特性正在陆续进入标准。当这些能力全部就位时，Firefox in WebAssembly 看起来就不会那么疯狂了。
Firefox 在浏览器市场份额中输掉了几乎一切，但它以另一种方式完成了穿越。当整个浏览器变成一个 WebAssembly 模块时，它不再是 Chrome 的对手，而是 Chrome 的容器。
快报