Wanix：浏览器中的 Wasm 原生 Unix 沙箱环境

日期：2026-07-23
主题：Wanix：浏览器中的 Wasm 原生 Unix 沙箱环境
原文：Wanix：浏览器中的 Wasm 原生 Unix 沙箱环境
来源：Lobsters / wanix.dev
领域：🕸️ Web 前端 / ⚙️ 操作系统

背景

你有没有想过，浏览器除了渲染网页、运行 JavaScript，还能做什么？

过去十年，浏览器悄悄变成了一个通用计算平台。从 WebAssembly 带来接近原生的执行速度，到 OPFS 提供持久化存储，到 Service Worker 构建离线能力——浏览器的能力边界在被不断推高。但有一个缺口始终存在：浏览器里没有一个真正的、可组合的操作系统环境。你想在浏览器里运行一个 shell、挂载一个文件系统、启动一个虚拟机，仍然需要远程服务器支持。

Wanix 试图填补这个缺口。它是一个完全在浏览器中运行的、Wasm 原生的 Unix 沙箱环境，灵感来源于 Plan 9 操作系统。通过几个自定义 HTML 标签，你可以在浏览器中启动一个完整的 Unix 环境——不需要服务器，不需要容器运行时，甚至连操作系统镜像都不需要。

核心内容

Plan 9 的精神，Wasm 的身躯

Wanix 的设计哲学深深植根于 Plan 9——贝尔实验室在 1990 年代开发的分布式操作系统。Plan 9 有几个核心理念，Wanix 将其一一移植到了 Web 平台：

一切都是文件（everything is a file）：在 Plan 9 中，硬件设备、网络连接、进程间通信统统被抽象为文件，挂载在统一的命名空间中。Wanix 将这个模型搬到了浏览器中——Wasm 程序、JavaScript 运行时、虚拟设备全部通过文件系统的命名空间来访问。
Per-process 命名空间：每个进程都有自己的命名空间视图，可以独立挂载、覆盖、联合不同的文件系统树。Wanix 的每个 <wanix-task>（任务元素）都运行在独立的命名空间中。
9P 协议：Plan 9 的分布式文件系统协议。Wanix 在 WebSocket 和 iframe 上实现了 9P 协议，使得不同浏览器标签页、甚至不同机器之间的命名空间可以相互导入导出。

但不同于 Plan 9 的是，Wanix 的"Unix 环境"不是模拟出来的——它是原生的。它的 shell（rc，Plan 9 的经典 shell）是用 Wasm 编译的，直接在浏览器的 Wasm 运行时中执行。它的文件系统（#ramfs、#web/opfs）是用 JavaScript 实现的虚拟设备，挂载在 Wasm 程序的命名空间中。这里没有 QEMU 转译层，没有 Docker 容器，没有远程 SSH——所有计算都在浏览器本地完成。

三行标签，启动一个 Unix 环境

Wanix 最令人惊叹的地方在于它的极简接口。要启动一个 Unix 环境，只需要三个 HTML 标签：

<wanix-term>
  <wanix-bind dst="rc.wasm" type="file" src="https://wanix.dev/extras/0.4.0-rc2/rc.wasm"></wanix-bind>
  <wanix-task cmd="rc.wasm" term start></wanix-task>
</wanix-term>

这个三行片段做了以下事情：

<wanix-bind> 将远程的 rc.wasm（Plan 9 的 shell 编译为 Wasm）绑定到命名空间中，相当于 curl 下载一个文件并挂载到文件系统。
<wanix-task> 在命名空间中启动 rc.wasm，分配一个终端（term），并立即启动（start）。
<wanix-term> 在页面上渲染一个 xterm.js 终端，连接到任务的终端输出。

加载完成后，你会在浏览器中看到一个 rc% 提示符——一个真正的 Unix shell 在浏览器中运行了。你可以 ls 查看文件、cat 读取内容，甚至运行其他 Wasm 程序。

这就是 Wanix 的核心交互模型：HTML 标签就是 API。不需要学习新的 SDK，不需要引入复杂的框架——你只需要在 HTML 中声明你想要的资源，Wanix 的运行时就会自动解析标签、建立命名空间、启动任务，全部在浏览器本地完成。

命名空间——Wanix 的核心抽象

命名空间（namespace）是 Wanix 中最核心的概念。Wanix 的每个顶级元素（如 <wanix-term>、<wanix-task>）都会隐式创建一个命名空间。你也可以用 <wanix-namespace> 显式创建和管理命名空间。

命名空间本质上是一个文件系统树，支持以下操作：

操作	元素/属性	说明
绑定文件	`<wanix-bind type="file">`	将远程 URL 或内联内容挂载为文件
绑定归档	`<wanix-bind type="archive">`	解压 `.tar`/`.tgz` 为目录树
绑定设备	`<wanix-bind dst="#ramfs">`	分配一个内存文件系统设备
导入命名空间	`<wanix-bind type="import">`	通过 9P/WebSocket 导入远程命名空间
联合挂载	多个 bind 到同一 `dst`	递归联合挂载，类似 Plan 9 的 union 目录

这种设计使得文件系统的组合变得极其灵活。你可以把多个归档绑定到同一个路径形成联合文件系统，可以把一个浏览器标签页中的命名空间导出到另一个标签页，甚至可以把来自不同机器的命名空间通过 9P 协议拼接到一起。

从 shell 到虚拟机

除了运行 Wasm 程序，Wanix 还支持通过 v86 模拟器启动完整的 Linux 虚拟机：

<wanix-vm>
  <wanix-bind dst="kernel" type="file" src="https://.../bzImage"></wanix-bind>
  <wanix-bind dst="rootfs" type="archive" src="https://.../rootfs.tar.gz"></wanix-bind>
  <wanix-task cmd="kernel" term start></wanix-task>
</wanix-vm>

这启动了一个完整的 Linux 内核（通过 v86 x86 模拟器），挂载了 Alpine/Busybox 根文件系统，分配了串口终端。你可以在这个虚拟机中 ls /bin、cat /etc/os-release，就像在真实的 Linux 服务器上一样——但所有计算都在浏览器中完成。

更有趣的是，Wanix 支持将虚拟机的内部命名空间导出（export="ttyS0"），使得外部任务可以 bind 到虚拟机内部的命名空间。这意味着你可以从浏览器页面中访问虚拟机内的文件系统，实现宿主机与客户机之间的无缝文件交换。

Workbench——浏览器中的 VS Code

Wanix 还提供了一个 Workbench 组件（<wanix-workbench>），它本质上是一个嵌入式 VS Code 界面，但后端文件系统直接挂载在 Wanix 命名空间上。这意味着：

你可以用 VS Code 界面编辑命名空间中的文件
可以打开终端执行 Wasm 程序
可以启动虚拟机并在 Workbench 中管理文件
多个标签页可以共享同一命名空间

Workbench 将"浏览器即开发环境"的愿景推向了一个新高度——你不需要在服务器上安装任何东西，只需要一个浏览器标签页，就拥有了一个 Unix 环境、一个文件系统、一个代码编辑器，以及一个终端。

总结与展望

Wanix 代表了一种大胆的技术方向：让浏览器成为真正的操作系统。它不是又一个在浏览器中模拟终端的玩具，而是一个从底层重新设计的、基于 Wasm 和 Plan 9 哲学的操作系统环境。

它的意义不仅在于技术实现本身，更在于它所指向的未来：

Local-first 计算的终极形态：如果应用代码和数据可以在浏览器中的 Unix 环境里运行，为什么还需要 SaaS 服务器？
Web 作为通用沙箱：Wanix 提供了一个比 iframe 更强大、比 Web Worker 更灵活的安全沙箱模型——每个任务有自己的命名空间，权限控制通过 bind 操作天然实现。
边缘计算的简化：当浏览器本身就能运行 Unix 程序和服务，边缘节点可以简化为一个浏览器进程，而不需要复杂的容器编排。

当然，Wanix 仍在早期阶段（当前版本 0.4）。它的性能、兼容性和安全性还有待大规模验证。但它的方向已经足够明确——未来的 Web 不再只是一个文档和应用的展示平台，它本身就是一个计算平台。Wanix 让我们提前看到了这个未来的样子。