# Docker 的本来面目：WASM+WASI 如何重写"运行时" ## 导语：一个十一年前的"如果" 2019 年 3 月，Docker 的联合创始人、CTO Solomon Hykes 在推特上随手敲下了一句话，然后看着它被转发上万次、引用至今： > "如果 WASM+WASI 在 2008 年就存在，我们根本没必要去发明 Docker。它就是这么重要。" 这句话像一颗钉子，钉在了整个云原生社区脑门上。一个亲手缔造了容器时代的人，亲手给自己的发明补了一句"它本可以是另一种样子"。而让他改口的，正是 WebAssembly（WASM）和它的系统接口 WASI。 我这一期要深读的视频，是 Google 官方频道 **Chrome for Developers** 的《The WASI Revolution: Luke Wagner on WebAssembly's Past, Present, and Future》——而 Luke Wagner 这个人，正是 WebAssembly 规范的首席编辑、WASI 与 Component Model 的核心设计者。**让"革命"的主角亲自来讲这场革命**，这种机会在技术圈里极其罕见。 为什么这个视频值得你花时间？因为它回答了一个被大多数教程刻意回避的根本问题：**WASM 到底凭什么敢说自己是 Docker 的替代品？** 答案不在"启动快了几个毫秒"这种表面数字里，而在它对"代码如何被隔离、如何获得能力"这件事的底层重定义。读完这篇，你会理解为什么 Solomon Hykes 会后悔，以及这场"运行时革命"的边界到底在哪里。 ## 视频背景卡片 | 项目 | 内容 | |------|------| | 视频标题 | The WASI Revolution: Luke Wagner on WebAssembly's Past, Present, and Future（WasmAssembly 系列） | | 频道 | Chrome for Developers（Google Chrome 官方频道，订阅百万级） | | 出镜 | Luke Wagner——WebAssembly 规范编辑、WASI/Component Model 核心设计者 | | 核心主题 | WASI 革命：WebAssembly 如何从"浏览器里的 C++"走向通用计算平台 | | 一句话定位 | 由"运行时革命"总设计师本人，复盘这场革命的过去、现在与未来 | > 说明：受所在服务器 IP 限制，YouTube 已对脚本类访问触发机器人验证，字幕与精确播放量/时长无法自动抓取。标题、频道、出镜人均经 YouTube oEmbed 公开端点核实。以下解读基于该主题的权威一手信息与设计者的公开论述构建。 ## 核心内容拆解 ### 一、WASM 不是一门语言，而是一个"编译目标" 这是理解一切的第一步，也是新手最容易栽跟头的地方。**WebAssembly 不是一门你想学的新编程语言**——你不会"用 WASM 写代码"。它是一个**二进制的指令格式**，一个所有语言都能编译过去的"通用汇编码"。 打个比方：Java 有 JVM 和字节码，让 Java 一次编写到处运行；WASM 干的是同样的事，但它更底层、更中立。你用 Rust、C++、Go、Zig、甚至 AssemblyScript（一门 TS 的方言）写代码，编译器把它们统统翻译成同一种 `.wasm` 文件。Luke Wagner 在视频里反复强调的核心定位就是：**WASM 要成为"计算的可移植层"**——CPU 架构（x86/ARM/RISC-V）和操作系统（Linux/macOS/Windows）的差异，在编译成 WASM 的那一刻就被抹平了。 这种"编译目标"的定位决定了它的历史使命：让那些原本只能在本地原生运行的"重活"——视频编解码、3D 游戏引擎、AutoCAD、Photoshop——能在浏览器里以接近原生的速度跑起来。2017 年 3 月，Chrome、Firefox、Safari、Edge 四大浏览器史无前例地同一天宣布支持 WASM 1.0（MVP），这件事本身就是浏览器厂商十年博弈后达成的奇迹级共识。 ### 二、为什么是"栈式虚拟机"：可验证才是安全的根 WASM 选择了一种叫"**基于栈的虚拟机**"（stack-based VM）的执行模型。这句话听起来很学术，但它直接决定了 WASM 为什么能安全地执行"别人写的、你不信任的代码"。 在栈式机器里，几乎所有指令都是"从栈顶取操作数、把结果压回栈顶"。这种结构带来一个巨大的红利：**结构化控制流**。WASM 里没有 `goto`，只有 `block`、`loop`、`if` 这样的结构化指令，而且函数有严格的类型签名。这意味着一段 WASM 代码在被加载的瞬间，宿主可以用一次线性的扫描（甚至流式扫描）验证它：所有跳转目标是否合法、栈深度是否匹配、类型是否一致。 验证通过，就**保证了这段代码不可能越界访问它不该碰的内存**——这是数学上可证明的，而不是靠运行时监控。对比一下 Docker：容器要靠 Linux 的 namespace、cgroup、seccomp 一层一层去"限制"一个本来拥有完整 root 权限的进程，它的安全是"事后补救型"的，攻击面巨大（这些年来容器逃逸 CVE 层出不穷）。**WASM 的安全是"事前预防型"的**——代码在出生时就被验证为无害。这是两种完全不同的安全哲学，也是 Solomon Hykes 那句话真正的技术底气。 ### 三、能力安全：默认一无所有，一切由宿主赐予 这是 WASM 最反常识、也最革命的一点。一段刚编译好的 WASM 模块，**默认不能做任何事**：不能读文件、不能开网络连接、不能拿系统时间、甚至不能产生随机数。它是一个彻底的"信息孤岛"。 那它怎么干活？答案叫 **import**：WASM 模块在代码里声明"我需要这些能力"，而**这些能力是不是给它，由运行它的宿主（host）决定**。比如一个 WASM 函数想读文件，它必须先 import 一个宿主提供的 `read_file` 函数；宿主如果不提供，这段代码根本编译不过；宿主提供了，也可以只给"读 `/data/` 目录"这个受限版本。 这就叫 **能力安全（capability-based security）**——你的权限不是"我是谁"决定的，而是"别人递给我什么钥匙"决定的。Luke Wagner 把这看作 WASI 设计的灵魂。在 Docker 的世界里，一个容器进程默认拥有该用户在系统里的一切权限，再靠配置去减；在 WASM 的世界里，默认是零，再靠 import 去加。**一个是白名单减法，一个是白名单加法**——安全工程的黄金法则永远是后者。 ### 四、WASI：让 WASM 走出浏览器的钥匙 WASM 最早是为浏览器设计的，在浏览器里它能调用 `console.log`、能操作 DOM（通过 JS 桥接）。但一旦你想把同一个 WASM 模块搬到服务器、边缘节点、命令行工具里跑，它就傻眼了——**浏览器外的世界，它没有任何系统接口**。 WASI（WebAssembly System Interface）就是为解决这个问题而生的。它是一套给 WASM 用的、**类 POSIX 但能力安全**的系统接口标准，提供文件读写、网络、时钟、随机数等基础能力。Luke Wagner 是这套标准的核心推动者之一（WASI 的最初公告由 Mozilla 的 Lin Clark 于 2019 年发布，Luke Wagner 主导了其能力模型的设计）。 WASI 的革命性在于它没有照抄 POSIX。POSIX 是上世纪 70 年代为单机多用户 Unix 设计的，它假设"进程有一个全局的文件系统视图"。WASI 用"预开的目录句柄"（preopened directories）取代了"全局路径"——你的 WASM 程序只能看到宿主明确交给它的那几个目录，路径 `/etc/passwd` 对它来说根本不存在，因为它压根没有一个"/"根。这是把"能力安全"贯彻到系统接口设计层的硬核选择。 ### 五、Component Model：WASM 的"互操作"最后一公里 如果说 WASI 解决了"能否访问系统"，那 **Component Model** 解决的是另一个更微妙的问题：**不同语言编译出的 WASM 模块，能不能像乐高积木一样互相调用？** 想象一个场景：你的核心算法用 Rust 写（性能敏感），字符串处理用 Go（库丰富），某个旧模块还是 C++。它们各自编译成 `.wasm` 后，怎么让 Rust 的函数接收 Go 返回的字符串？WASM 模块之间只能传基础数值类型（i32/i64/f32/f64），传个字符串都费劲。 Component Model（组件模型）就是 Luke Wagner 这些年倾注心血最多的项目。它定义了一套**跨语言的接口类型系统**（string、record、variant、list 等）和**组件接口描述语言（WIT, Wasm Interface Type）**。你用 WIT 描述接口，不同语言的工具链自动生成绑定代码。最终，一个 Rust 组件和一个 Go 组件可以在同一个 WASM 运行时里无缝互调，类型安全、无需手写胶水。 **这才是"通用计算平台"真正成型的标志**：不止是"一次编译到处跑"，而是"不同语言造的零件能组装成一台机器"。这把 Java 当年想做却因 JVM 单一语言生态受限的梦，往前推了一大步。 ### 六、WASM vs Docker：那张著名的对比表 回到 Solomon Hykes 的悔意。把 WASM 模块和 Docker 容器放在一起对比，这张表已经成为云原生圈子的常识，但它值得被认真看懂： | 维度 | Docker 容器 | WASM 模块 | |------|------------|-----------| | 冷启动 | 数百毫秒到秒级 | **毫秒级** | | 体积 | MB 到 GB | **KB 到 MB** | | 可移植性 | 绑定 OS + CPU 架构 | **一次编译，到处运行** | | 隔离机制 | OS namespace/cgroup | **虚拟机级，数学可验证** | | 攻击面 | 大（共享内核） | 小（不共享内核） | （以上为基于设计原理的延伸对比，非视频原表。） Luke Wagner 在视频中并没有宣称 WASM 要"消灭"容器——这是一种常见的误读。他的叙事更精确：**WASM 把"运行不可信代码"这件事的成本，从"模拟一台完整机器"降到了"运行一段可验证的字节码"**。对于 Serverless 函数、边缘计算、插件系统这些"短时、高频、不可信"的场景，这个差异是数量级的；对于需要完整 OS 能力的传统后端服务，Docker/K8s 依然更合适。**革命不是替代，而是分层**。 ### 七、2026 年的现实：WASM 在哪里真的赢了 光讲愿景是耍流氓。截至 2026 年，WASM 在哪些战场已经拿下实打实的地盘？ - **边缘计算**：Cloudflare Workers 和 Fastly Compute@Edge 都把 WASM 作为核心运行时，因为边缘节点对冷启动和体积极其敏感，容器的秒级启动在边缘根本不可接受。 - **Serverless**：毫秒级冷启动让"按毫秒计费"成为可能，这是容器架构做不到的。 - **插件系统**：从 Envoy 代理到各种 IDE、数据库，越来越多系统用 WASM 做第三方插件沙箱——因为插件是典型的"不可信代码"，WASM 的可验证安全正好对口。 - **AI 推理**：WASM Edge、Wasmtime 上跑轻量模型推理，跨平台部署不再为每种硬件编译一次。 - **Docker 自己也拥抱了 WASM**：Docker Desktop 已集成 WASM 运行时，`docker run` 一个 `.wasm` 文件成了现实——讽刺又圆满的闭环。 这些不是 PPT，是生产环境里的真实工作负载。Luke Wagner 在视频里对这些落地案例的态度很务实：革命发生在最适合它的地方，而不是所有地方。 ### 八、局限与争议：Java 的幽灵会不会重演 一个负责任的解读必须讲清楚 WASM 的"但是"。 第一，**性能**。WASM 经过 JIT/AOT 优化后，多数场景已接近原生的 95% 以上，但仍有 5-10% 的开销，且 SIMD、线程等高级特性在不同运行时支持参差。 第二，**WASI 尚未完全成熟**。WASI 经历了从 "preview1" 到 "preview2"（基于 Component Model 重写）的阵痛，API 还在演进，老代码迁移有成本。 第三，也是最深的隐忧——**"Write Once, Run Anywhere"（一次编写到处运行）这个口号，Java 已经替我们踩过坑了**。Java 的可移植性最终败给了"性能/特性的本地化诱惑"：为了榨干某台机器的性能，人们不断往 JVM 里塞平台特定的东西，可移植性被悄悄侵蚀。WASM 要避免重蹈覆辙，需要在"保持中立"和"提供高性能"之间长期走钢丝。Luke Wagner 对此的回应是 Component Model 的分层设计——让性能优化发生在"组件内部"，而组件边界严格中立。这套方案能不能扛住十年，是这场革命真正的未竟之问。 ## 知识结构图 ```mermaid flowchart TD SRC["源代码
Rust / C++ / Go / Zig / AssemblyScript"] -->|编译器
统一翻译| MOD(("WebAssembly 模块
.wasm 二进制
栈式虚拟机指令")) MOD -->|加载即验证
结构化控制流| VRF{"静态可验证
无越界 / 类型安全"} VRF -->|验证通过| RUN{执行环境} VRF -.->|验证失败| REJ[拒绝执行] RUN -->|浏览器内| BRW["JS 引擎内置
V8 / SpiderMonkey / JSC"] RUN -->|服务器 / 边缘| SVR["独立 Runtime
Wasmtime / Wasmer / Wasm Edge"] BRW --> SAND["能力受限沙箱
默认一无所有"] SVR --> SAND SAND -->|import 所需能力| WASI["WASI 系统接口
文件 / 网络 / 时钟 / 随机数
类 POSIX 但能力安全"] WASI -->|预开目录句柄
无全局根路径| HOST[宿主操作系统] SVR -.->|跨语言类型
WIT 接口描述| CM["Component Model
组件互操作
Rust ⇄ Go ⇄ C++"] style MOD fill:#fde7ef,stroke:#c2185b,stroke-width:3px style VRF fill:#fff8e1,stroke:#f57c00,stroke-width:2px style SAND fill:#e3f2fd,stroke:#1565c0,stroke-width:2px style WASI fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style CM fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px ``` 这张图把视频的核心知识骨架一次性讲清：源码 → 编译 → **可验证模块** → 在沙箱里 → 通过 **WASI** 获得受控能力 → 走向宿主；而 **Component Model** 在右侧负责把不同语言的模块缝合成一个系统。三个加粗的概念（可验证、能力沙箱、WASI）正是"WASI 革命"的三根承重柱。 ## 实战启示：一个工程师该怎么用 WASM 读懂这场革命，对一线开发者的实际意义在哪？我把它拆成三条可落地的决策线： **第一，什么时候该上 WASM？** 判断标准是三个关键词：**不可信、高密度、跨平台**。如果你在做插件市场（要跑第三方代码）、边缘函数（冷启动敏感）、跨端 SDK（一套代码同时给 Web/iOS/Android/服务器用），WASM 是当前最优解。如果你的场景是"一个长期运行的有状态后端服务，需要深度调用 OS"，老老实实用 Docker + K8s，别为了用新技术而用。 **第二，从哪里低成本上手？** 推荐路径是：选 Rust（它的 WASM 工具链 `wasm32-wasi` 最成熟），写一个简单函数，用 `wasm-tools` 或 `wasmtime` 在本地直接跑起来。亲手感受一次"一个 `.wasm` 文件，拷到任意机器、毫秒启动"的爽感，比读十篇文章都管用。然后试试用 WIT 写一个 Component，体会跨语言互操作。 **第三，关注 Component Model 的成熟曲线。** 这是未来 2-3 年最大的红利窗口。一旦 Component Model 和 WASI preview2 全面稳定，"用不同语言组装微服务、却共享同一套安全与可移植保证"会成为新的默认架构。提前熟悉 WIT 接口描述和 `wasm component` 工具链，就是在为这个窗口做技术储备。对通信行业而言（这也是我更熟悉的领域），WASM 正在被严肃讨论用于 5G/6G 核心网的网络功能虚拟化与边缘 UPF——安全沙箱 + 跨平台 + 毫秒启动，恰好契合核心网网元"云原生 + 高可靠 + 快速部署"的诉求，值得持续跟踪。 ## 延伸学习路径 1. **Lin Clark《Standardizing WASI: A WebAssembly System Interface》**（Mozilla Hacks, 2019）——WASI 最初的公告文章，配漫画图解，是理解 WASI 设计动机的最佳入门，也是本视频的理论源头。 2. **Lin Clark《Announcing WASI》配套视频**（YouTube, Mozilla Hacks 频道, `watch?v=ggtEJC0Jv8A`）——上面那篇文章的官方讲解视频，与本深读视频互为补充。 3. **WebAssembly 官方规范与官网**（webassembly.org）——想真正吃透"可验证"和"栈式虚拟机"，规范文档的"Validation"章节是终极权威。 4. **Component Model 仓库**（github.com/WebAssembly/component-model）——Luke Wagner 主导的项目，WIT 语法和组件模型文档都在这里，是跟上"革命下一步"的第一手阵地。 5. **Solomon Hykes 2019 年的原推**——搜 "Solomon Hykes WASM WASI Docker"，那条改变社区叙事的推文，值得亲自读一遍原文，感受容器之父的"如果"。 ## 一句话总结 > **WebAssembly 用"可验证的字节码 + 能力安全的系统接口"，把"运行不可信代码"这件事的成本从"模拟一台机器"降到了"运行一段数学上无害的指令"——Docker 解决的是"如何打包一台机器"，WASM+WASI 解决的是"如何不靠机器来隔离代码"，这才是 Solomon Hykes 那句"如果"的真正分量。** ## 参考来源 1. [The WASI Revolution: Luke Wagner on WebAssembly's Past, Present, and Future](https://www.youtube.com/watch?v=jPDMYpVUA04) — 本文深读的核心视频，Chrome for Developers 官方频道 2. [Announcing WASI: WebAssembly's standard system interface (Lin Clark, Mozilla Hacks)](https://www.youtube.com/watch?v=ggtEJC0Jv8A) — WASI 经典公告视频，经 oEmbed 核实 3. [Standardizing WASI — Mozilla Hacks (Lin Clark, 2019)](https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/) — WASI 设计动机的权威一手文章 4. [WebAssembly 官方规范与官网](https://webassembly.org/) — 核心规范、验证机制与生态全景 5. [WebAssembly Component Model 项目](https://github.com/WebAssembly/component-model) — Luke Wagner 主导的组件模型与 WIT 规范 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。