浏览器里跑着真引擎：WebAssembly 开发工具集

• 引言 — 无需安装、无需服务器、数据不外泄
• WebAssembly 为什么改变了游戏规则
• WASM 模块是如何加载的
• 语言练习场 — 真正的解释器在运行
• 数据库与数据工具 — 在浏览器里跑 SQL
• 构建与编译工具 — 工具链搬进了浏览器
• 媒体与图像 — ffmpeg 与 ImageMagick 整个搬来
• 其他工具 — AI、模拟器、仿真器
• 现实中的局限 — WASM 做不到的事
• 结语
• 参考资料

引言 — 无需安装、无需服务器、数据不外泄

过去几周里，我在这个网站上一口气加了一批浏览器工具：Python 解释器、PostgreSQL 数据库、视频转换器，甚至还有 x86 PC 模拟器。它们有一个共同点 — 不是仿制品，而是真家伙。Python 练习场跑的是真正的 CPython，SQL 练习场跑的是真正的 SQLite。而这一切都发生在没有后端、只在你浏览器标签页内部的环境里。

让这一切成为可能的技术是 WebAssembly(简称 WASM)。这篇文章不是营销文案，而是聊聊 WASM 到底解决了什么、还有什么做不到，以及在它之上做的这些工具该怎么用。

WebAssembly 为什么改变了游戏规则

WebAssembly 是一种在浏览器里运行的低层字节码格式。它不是要取代 JavaScript，而是接手 JavaScript 不擅长的那部分工作。核心优势有四条。

• 接近原生的速度：WASM 是预编译的二进制格式，解析快，并通过 JIT/AOT 执行到接近机器码的水平。用 C、C++、Rust 写的重型引擎也能跑出实用的速度。
• 语言可移植性：只要能通过 LLVM 或专用工具链编译，几乎任何语言都能移植到 WASM。CPython、CRuby、SQLite、ffmpeg 这类既有的 C/Rust 代码库，几乎原封不动地被搬进了浏览器。
• 沙盒隔离：WASM 模块默认运行在内存和系统访问都被封锁的沙盒里。只能使用宿主(JavaScript)明确交出来的能力，因此运行不受信任的代码也是安全的。
• 无需服务器 + 隐私：因为全部运算都在客户端进行，不需要服务器。结果是，输入数据永远不会离开浏览器。你不必上传照片、代码或文档。

最后这一条在实务中分量尤其重。转换 iPhone 的 HEIC 照片，或者用 SQL 拆解公司日志时，数据不会被发送到任何服务器 — 这不只是便利,而是一项安全要求。

WASM 模块是如何加载的

浏览器运行一个 WASM 工具，大致流程如下。

  1. 页面加载
        |
        v
  2. 下载 .wasm 二进制文件(CDN 或自托管)
        |
        v
  3. 用 WebAssembly.instantiate() 编译 + 实例化
        |
        v
  4. JavaScript 注入宿主函数(文件、控制台等)
        |
        v
  5. 引擎运行 — 此后的运算全部在本地进行

.wasm 文件从 CDN 获取，或者由网站直接托管。像 Python 这样的大型运行时,下载体积可达数 MB 到数十 MB,因此首次加载需要一点时间。作为交换,浏览器会缓存这个文件,所以第二次开始会快得多。这就是「只有第一次慢,之后立刻响应」的原因。

有一点要注意,是隔离要求。使用线程或共享内存(SharedArrayBuffer)的重型 WASM 工具,可能需要浏览器的跨源隔离(COOP/COEP)响应头。ffmpeg 的多线程构建就是典型例子。只有网站正确设置了这些响应头,该功能才会开启。

语言练习场 — 真正的解释器在运行

最直观的用法,是把整门编程语言塞进浏览器。这些不是只做语法高亮的编辑器,而是真正在运行解释器。

• Python 练习场运行由 Pyodide 编译的真正 CPython 3.14。print 输出会被原样捕获,需要的话还能安装 numpy。
• Ruby 练习场用 ruby.wasm 跑 CRuby 3.4。块、类、模式匹配,统统是真正的 Ruby 语义。
• PHP 练习场用 WordPress Playground 的 WASM 引擎运行 PHP 8.3。
• Lua 练习场用 wasmoon 跑 Lua 5.4。表、元表、协程都能用。

举个简单的例子,在 Python 练习场里输入下面这段代码,不经过服务器往返就能立刻拿到结果。

def fib(n):
    a, b = 0, 1
    for _ in range(n):
        a, b = b, a + b
    return a

print([fib(i) for i in range(10)])
# [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

关键在于,这个结果不是「预先存好的标准答案」。改动代码,真正的解释器会重新执行。

数据库与数据工具 — 在浏览器里跑 SQL

数据类工具尤其能体现 WASM 的价值,因为真正的数据库引擎就在标签页里运转。

• SQL 练习场用 WASM 运行真正的 SQLite。可以在示例数据库上练习 JOIN、GROUP BY、窗口函数,并把结果导出为 CSV。
• PostgreSQL 练习场用 PGlite 跑真正的 PostgreSQL 18。JSONB、全文搜索、递归 CTE、EXPLAIN ANALYZE,全都以真实的 Postgres 语法运作,还能把数据持久化到 IndexedDB。
• DuckDB 数据分析练习场用 DuckDB-Wasm 以 SQL 分析 CSV、JSON、Parquet。可以使用 SUMMARIZE、PIVOT 这类分析特化语法。
• jq 练习场用 jq 过滤器实时加工 JSON。

比如在 Postgres 练习场里,下面这条递归 CTE 会实际执行。

WITH RECURSIVE counter(n) AS (
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM counter WHERE n < 5
)
SELECT n, n * n AS square FROM counter;

因为数据不会离开浏览器,粘贴敏感 CSV 进去分析也是安全的。这是大多数在线 SQL 工具做不到的一点。

构建与编译工具 — 工具链搬进了浏览器

构建工具恰恰是最需要原生性能的领域,而托 WASM 的福,它们也进了浏览器。

• SWC 练习场运行用 Rust 写的超高速编译器 SWC,转译 TypeScript/JSX,还能显示 AST。
• esbuild 练习场用 esbuild-wasm 执行转换和打包。
• Sass/SCSS 编译器用 dart-sass 把 SCSS 编译成 CSS。
• Graphviz 渲染器把 DOT 语言绘制成 SVG 图。
• Typst 练习场运行用 Rust 写的 Typst 排版引擎,把 LaTeX 替代方案的文档输出为 PDF。
• WebAssembly 工作室用 wabt 把 WAT(WebAssembly 文本)编译成二进制,展示十六进制转储和反汇编,还能真正执行它。相当于用 WASM 来学 WASM。

它们的共同点是没有「安装地狱」。不需要 node_modules,不需要本地工具链,打开链接编译器就跑起来了。

媒体与图像 — ffmpeg 与 ImageMagick 整个搬来

媒体处理传统上是重型原生库的地盘。如今它们也在浏览器里运行了。

• 视频转换器用 ffmpeg.wasm 把视频转成 GIF、提取音频,处理裁剪、缩放、变速。没有文件上传。
• 万能图像转换器用真正的 ImageMagick 引擎(WASM)读取 iPhone HEIC、TIFF、PSD 等 270 多种格式,转换为 JPG、PNG、WebP、AVIF。
• OCR 文本提取器用 Tesseract WASM 从图像中提取韩语、英语、日语文字。
• ASCII 艺术转换器把照片变成字符画。

视频转换是同时展示 WASM 局限与优势的好例子。它比原生 ffmpeg 慢,但把短片段转成 GIF 这种程度完全够用,更重要的是,视频文件不会被上传到服务器。

其他工具 — AI、模拟器、仿真器

WASM 的应用超越了语言和媒体。

• 浏览器 AI 实验室用 Transformers.js(ONNX 运行时)在没有服务器的情况下执行情感分析、嵌入相似度、韩英互译、零样本分类、摘要生成。有 WebGPU 的话,还能用上 GPU 加速。输入文本不会被发送到任何地方。
• 浏览器 PC 模拟器用 v86 启动真正的 x86 PC。一键启动 FreeDOS,或者启动自己的 .img/.iso 镜像。
• Git 实习场、网页终端、Linux 终端模拟命令行练习环境。
• eBPF 练习场模拟 eBPF 指令集和内核验证器。(不是真正的内核钩子,只是概念学习用。)
• 密码与哈希实验室和密码学学习让你在客户端练习 Argon2、SHA/HMAC、AES-GCM、RSA/ECDSA,以及古典密码与密码分析。

这份清单里能看出两条线索。一条是把真正的引擎(AI 模型、x86 CPU、密码库)用 WASM 搬进来,另一条是将概念可视化的仿真器(git 图、eBPF 验证器)。后者并不运行真实系统,但为直观理解原理做了优化。

现实中的局限 — WASM 做不到的事

WASM 强大,但不是万能。在动手用这些工具之前,有几条局限值得了解。

• 首次加载体积:Python 或 Postgres 这类大型运行时,下载体积在数 MB 到数十 MB 之间。缓存能有所帮助,但首次访问是慢的。
• 比原生慢:是接近原生,不是原生本身。重型视频编码或大规模数据处理,比原生工具慢。
• 无法直接访问系统:因为是沙盒,不能随意访问任意文件系统、网络套接字或 GPU。只能使用浏览器许可的 API(File System Access、WebGPU 等)。所以即便是像 v86 这种启动真正 Linux 内核的工具,实际上也是运行在被模拟出来的硬件之上。
• 内存上限:基线 WASM 使用 32 位地址空间,因此内存有上限(Memory64 提案正在缓解这一点)。超大规模数据集会带来压力。
• 多线程是有条件的:要用线程,需要前面提到的隔离响应头,而且并非所有环境都会开启。

归纳起来,WASM 最适合「在没有服务器、又能保护隐私的前提下,做适度重的工作」。超大规模、超高性能的工作,依然是服务器或原生方案更胜一筹。

结语

WebAssembly 带来的变化,本质上是「在浏览器里使用重型工具,不需要任何安装,也不会有任何数据外泄」。真正的 CPython、真正的 PostgreSQL、真正的 ffmpeg 在你的标签页里运行,过程中代码和数据都不会外流。

局限也很明显。首次加载慢,不适合超高性能的工作。但对于学习、实验、处理敏感数据这类大多数日常工作而言,已经绰绰有余。把上面链接的工具一个个打开看看吧。没有服务器却能做到这个程度,这个事实相当令人惊讶。

参考资料

• WebAssembly 官方网站: https://webassembly.org/
• MDN WebAssembly 指南: https://developer.mozilla.org/en-US/docs/WebAssembly
• Pyodide: https://pyodide.org/
• PGlite: https://pglite.dev/
• DuckDB-Wasm: https://duckdb.org/docs/api/wasm/overview
• Transformers.js: https://huggingface.co/docs/transformers.js
• ffmpeg.wasm: https://ffmpegwasm.netlify.app/