# 如果WASM早诞生，就不会有Docker：一场容器王国的颠覆猜想 2019年3月，Docker联合创始人 Solomon Hykes 在推特上随手敲下一句话：**"如果 WASM+WASI 在2008年就存在，我们根本不需要创造 Docker。"** 这条只有一行字的推文，在随后七年里被反复引用、反复解读，成了云原生圈最著名的一句"预言"。问题在于——大多数引用它的人，其实没真正理解这句话的重量。一个亲手把容器技术推向全世界的人，为什么会说自己造的东西"本不该存在"？最近在 YouTube 上走红的编程深度视频《WASM might replace Containers》（WASM 可能取代容器）恰恰把这个问题摆到了台面上：它不满足于科普 WebAssembly 是什么，而是直接拆解了一个更具挑衅性的命题——**在2026年的今天，Docker 容器这套统治了十三年的软件打包范式，是否正迎来真正的终结者？** 配合刚刚在 2026-06-13 正式发布的 WebAssembly 3.0 规范，这个问题的现实意义比以往任何时候都更强。这篇文章就带你把视频里的核心论点掰开揉碎，并补上视频没讲透的底层逻辑。 ## 视频背景卡片 | 项目 | 内容 | |------|------| | 视频标题 | WASM might replace Containers | | 视频链接 | https://www.youtube.com/watch?v=bPDbXPFFI9w | | 核心主题 | WebAssembly + WASI 为何可能取代 Docker 容器 | | 关键概念 | WebAssembly、WASI、组件模型(Component Model)、能力安全(Capability Security)、冷启动 | | 历史锚点 | Solomon Hykes 2019年关于"如果 WASM 早就存在就不需要 Docker"的推文 | | 时效背景 | WebAssembly 3.0 规范于 2026-06-13 发布；WASI Preview 0.3 与组件模型在2026年走向生产可用 | | 适合人群 | 后端工程师、云原生/平台工程从业者、对软件架构演进感兴趣的开发者 | ## 核心内容拆解 ### 一、Solomon Hykes 的"预言"不是客套，而是历史的反讽 要听懂这句话，得先回到 Docker 解决的那个核心痛点。在容器出现之前，软件交付是一场灾难：开发者在自己机器上跑得好好的程序，到了服务器上就因为库版本、操作系统差异、依赖冲突而崩溃——这就是臭名昭著的 "works on my machine"（在我机器上能跑）问题。Docker 的天才之处在于：**把应用连同它所有依赖，一起塞进一个隔离的 Linux 命名空间和 cgroup 里，打成一个镜像**，于是"构建一次，到处运行"终于大规模兑现了。 但 Solomon Hykes 的潜台词很尖锐：容器本质上是一种**打补丁式的方案**。它依赖宿主机内核，强绑定了 Linux 这套 syscall 体系，隔离边界是操作系统级别的，安全性靠的是"你只能调用我没禁止的东西"（黑名单模型）。如果有一种技术，从设计第一天起就内置了真正的沙箱、跨平台字节码和精细的能力授权，那么容器这套复杂的基础设施很多根本不需要存在。视频强调：Solomon 说这句话时，WASM 还远未成熟，这更像是一个架构师对自己作品局限性的诚实复盘。**理解了这个反讽，才能理解为什么整个云原生社区这些年都在认真对待"WASM 取代容器"这个命题——它不是营销噱头，而是来自容器发明者本人的方向指引。**（延伸分析：这是我的解读，视频中点到了这句名言但未做此深度展开。） ### 二、从浏览器越狱：WASM 的本质到底是什么 很多人对 WebAssembly 的认知停留在"前端性能优化工具"——把 C++/Rust 编译成二进制跑在网页里，让 Figma、Photoshop 网页版飞起来。这只说对了它的诞生背景。WASM 的真正本质，视频把它定义为四件事的组合：**第一，它是一种紧凑的二进制指令格式**，体积远小于 Docker 镜像（动辄几百 MB 甚至几个 GB，而一个 Wasm 模块常以 KB/MB 计）；**第二，它运行在一台"栈式虚拟机"上**，这意味着它不绑定任何具体 CPU 架构或操作系统，x86、ARM、RISC-V 都能跑同一份二进制——这是比容器更彻底的"一次编写到处运行"；**第三，它从第一天就是安全沙箱**，默认情况下 Wasm 代码碰不到文件系统、碰不到网络、碰不到任何系统资源，能力必须被显式授予；**第四，它的执行模型可以接近原生速度**，通过 JIT/AOT 编译，性能损耗通常在个位数百分比。 关键洞察在于：**这四条加在一起，恰好是容器想做却没做好的事。** Docker 镜像大、强绑定 Linux、隔离靠内核特性、安全靠补丁；而 WASM 是轻量、跨平台、原生沙箱、接近原生速度。这就是为什么 Solomon Hykes 会说"如果它早存在"——容器某种程度上是在用操作系统机制，去笨拙地模拟一个本该由语言运行时完成的工作。（这部分是行业共识，视频做了通俗化讲解。） ### 三、WASI：让 WASM 走出浏览器的钥匙 WASM 在浏览器里风光了很多年，但一直没法"逃出浏览器"，原因很简单：浏览器里的 Wasm 不需要碰系统资源，V8 引擎替它挡住了一切。可一旦你想在服务器上跑 Wasm——比如读个文件、开个 socket——它就无能为力了。这正是 **WASI（WebAssembly System Interface，WebAssembly 系统接口）** 要解决的问题。WASI 是一套标准化的、可移植的"系统调用"接口，让 Wasm 模块能安全地访问操作系统资源。 视频在这里抛出了我认为全片最关键的一个技术对比：**安全模型的根本差异。** Docker/容器的安全是"黑名单"式的——默认给你几乎全部 Linux 能力，然后用 seccomp、AppArmor、rootless 之类一层层封堵你"不该有"的权限，所以才会不断爆出容器逃逸漏洞。而 WASI 是"白名单/能力"式的——默认你什么都没有，主机把"读这个文件""连这个网络"当作一个个**能力（capability）**显式地、按需地交给你。**这是两种截然不同的安全哲学：一个假设默认可信、事后封堵，一个假设默认不可信、事前授权。** 在一个零信任和供应链攻击频发的年代，后者的优势不言而喻。WASI Preview 0.3 在2026年已趋于稳定，加上 Wasm 3.0 规范刚于 2026-06-13 发布，WASI 这把"钥匙"终于打磨得可以真正开锁了。 ### 四、组件模型：跨语言的乐高积木，WASM 生态的胜负手 如果说 WASI 解决了"能不能跑"，那么**组件模型（Component Model）** 解决的是"能不能协作"——这是视频里篇幅有限、却最被低估的一个议题。早期 WASM 模块有个致命短板：每个模块只能用线性内存，模块之间没法直接、安全地传递复杂数据结构。这意味着你没法把一个用 Rust 写的 Wasm 加密模块，和另一个用 Go 写的 Wasm 路由模块，像乐高一样拼起来。 组件模型正是为打破这种"孤岛"而设计的：它定义了一套**跨语言的接口类型系统（Interface Types）和组件间调用协议**。结果是革命性的——你可以用 Rust 写一个核心算法，编译成组件；用 JavaScript/Python 写业务逻辑，编译成组件；用 C++ 写性能关键路径，编译成组件。**这些用不同语言写、分别编译的组件，可以在同一个 Wasm 运行时里无缝互相调用，就像在同一个进程里调函数一样。** 这套机制在2026年走向成熟，是 WASM 能不能从"边缘玩具"升级为"通用运行时"的胜负手。字节码联盟（Bytecode Alliance，成员包括 Mozilla、Fastly、Intel、微软等）主推的 Wasmtime、Fermyon 的 Spin、Cosmonic 的 wasmCloud 都已围绕组件模型构建生态。（这部分是我基于字节码联盟公开文档的延伸，视频点到为止。） ### 五、冷启动屠杀：微秒对秒的降维打击 落到具体数字上，WASM 对容器最致命的一击在**冷启动（cold start）**。容器启动要做的事很多：拉镜像、创建命名空间、启动 init 进程、加载运行时……这一切加起来，冷启动动辄几百毫秒到几秒，这也是为什么 AWS Lambda 早期被吐槽"首次请求慢得像断网"。而 Wasm 模块因为体积小、无系统级初始化开销，冷启动可以压到**亚毫秒级甚至微秒级**——多个生产环境基准显示标准云环境约 50–500ms，无服务器场景下可低于 1ms。 视频用一个生动的对比说明这意味着什么：**在边缘计算和按请求计费的无服务器场景里，冷启动每缩短一个数量级，商业模型就重写一次。** 如果你的函数每天被调用一亿次，每次冷启动省下几百毫秒，那就是巨大的成本和体验差距。更关键的是，WASM 可以实现真正的**密集多租户**——成千上万个 Wasm 模块可以塞进同一台机器、甚至同一个进程，彼此沙箱隔离，而容器因为每个实例都要一个完整 OS 用户态开销，根本做不到这种密度。这是为什么 Fastly、Cloudflare、Shopify 等边缘平台纷纷押注 Wasm 作为底层运行时。 ### 六、现实拷问：WASM 真的能干掉 Docker 吗 讲到这里，你可能会觉得 Docker 完蛋了——但视频和我都要泼一盆冷水：**"取代"这个词过于绝对，更准确的描述是"分层共存"。** WASM 目前还有几道硬伤：第一，**GPU 支持和重计算场景偏弱**，做机器学习推理、视频转码这类任务时，WASM 还难以媲美原生 CUDA；第二，**工具链和生态成熟度远不及 Docker**，Docker/Kubernetes 背后是十年沉淀的 Helm、Istio、可观测性全家桶；第三，**长驻服务、有状态的复杂应用**，容器依然是更现实的选择。 所以更可能的结局是：**未来不是一个吃掉另一个，而是各管一段。** 长驻的、重负载的、需要 GPU 和完整 OS 能力的后端服务继续跑在容器里；而短生命周期的、边缘的、对冷启动和安全敏感的工作负载——函数计算、插件系统、第三方扩展、跨平台 CLI 工具、浏览器内重计算——会越来越多迁移到 WASM。Solomon Hykes 的"预言"不会以"Docker 消亡"的方式实现，而会以"WASM 吃掉容器最不舒服的那一层市场"的方式逐步兑现。这才是 2026 年值得每个架构师关注的真实图景。 ## 知识结构图 ```text flowchart TD A[软件交付的"Works on my machine"痛点] --> B[Docker 容器: 2013年的补丁式方案] B --> B1[依赖宿主内核] B --> B2[黑名单安全模型] B --> B3[镜像体积大/冷启动慢] A --> C[WebAssembly: 从底层重新设计的方案] C --> C1[二进制指令格式 + 栈式虚拟机] C --> C2[原生沙箱 + 跨架构可移植] C --> C3[WASI 系统接口: 能力安全白名单模型] C --> C4[组件模型: 跨语言互操作] B3 -.对比.-> D{核心差异} C3 -.对比.-> D D --> E[冷启动: 秒级 vs 微秒/亚毫秒级] D --> F[安全: 黑名单封堵 vs 白名单授权] D --> G[体积: 百MB~GB vs KB~MB] C4 --> H[2026现实: 分层共存而非取代] H --> I[容器: 长驻服务 / GPU / 重负载] H --> J[WASM: 无服务器 / 边缘 / 插件 / 跨平台] K[WebAssembly 3.0 规范
2026-06-13 发布] --> C L[Solomon Hykes 2019 推文
Docker 创始人的自我反讽] -.指引.-> H ``` ## 实战启示 **如果你是后端/平台工程师，这段内容怎么落到你的工作里？** 我有三条具体建议。 第一，**别急着"迁移到 WASM"，而是先识别"WASM 友好型工作负载"**。判断标准很简单：生命周期短、冷启动敏感、需要强隔离或多租户密度。典型的甜点场景包括：SaaS 平台的第三方插件系统（用户上传代码，用 WASM 沙箱隔离执行，比 Docker 安全得多）、CLI 工具的跨平台分发（一份 `.wasm` 文件通吃 Win/Mac/Linux）、边缘函数和 AI 推理的轻量封装。如果你的系统是 7×24 长驻的微服务，老老实实用容器，别折腾。 第二，**把"能力安全"这个思维模型迁移到你的日常架构设计里**。即便你暂时不用 WASM，WASI 的"默认零权限、按需授权"哲学也值得借鉴。下次设计一个需要执行外部/不可信代码的系统时，问自己一个问题：我是不是又在用黑名单思维？能不能反过来，从"默认什么都没有"开始，再逐项授权？这个思维转换能让你少踩很多安全坑。 第三，**保持对组件模型的关注，这是下一个语言互操作的红利期**。如果你团队里同时有 Rust/Go/Python/TS 多语言栈，组件模型有望在未来一两年内显著降低跨语言调用的成本。现在花一两个周末用 Wasmtime 或 Fermyon Spin 跑个 demo，理解组件接口怎么定义、怎么跨语言调用，这笔投资在未来会回报得很丰厚。 ## 延伸学习路径 1. **WebAssembly 3.0 核心规范**（webassembly.github.io/spec/core/）— 2026-06-13 刚发布，想理解栈式虚拟机和指令集的原始权威来源。 2. **字节码联盟组件模型文档**（component-model.bytecodealliance.org）— 系统理解组件模型如何实现跨语言互操作，有完整示例。 3. **Solomon Hykes 2019 原推文及 Hacker News 讨论**（news.ycombinator.com/item?id=28109699）— 看社区当年如何解读这句"预言"，理解争议的来龙去脉。 4. **Fermyon Spin / Wasmtime 上手实践** — 两个最成熟的服务端 WASM 运行时，跟着官方教程跑通第一个组件应用。 5. **《Docker vs WebAssembly (2026)》深度对比系列**（wasmruntime.com 等多源）— 多角度对比两种隔离技术，适合架构决策参考。 ## 一句话总结 **Docker 容器是操作系统层面的"补丁"，而 WebAssembly 是从字节码层面重新发明的软件运行时——它不会消灭 Docker，但会吃掉容器最不舒服的那一层未来。** --- ## 参考来源 1. [WASM might replace Containers](https://www.youtube.com/watch?v=bPDbXPFFI9w) — 本文深度解读的核心视频，讨论 WebAssembly/WASI 为何可能取代 Docker 容器 2. [Solomon Hykes 原推文：If WASM+WASI existed in 2008, we wouldn't have needed to create Docker](https://x.com/solomonstre/status/1111004913224225) — Docker 联合创始人 2019 年的关键名言原文 3. [Hacker News 社区讨论](https://news.ycombinator.com/item?id=28109699) — 社区对 Solomon 名言的技术解读 4. [Docker vs WebAssembly (2026): When Containers Meet a Challenger](https://wasmruntime.com/en/blog/docker-vs-webassembly-2026) — 2026 年 Docker 与 WASM 全面对比 5. [WebAssembly 3.0 Specification (2026-06-13)](https://webassembly.github.io/spec/core/) — 最新 WASM 核心规范 6. [The WebAssembly Component Model](https://component-model.bytecodealliance.org/) — 字节码联盟组件模型官方文档 --- > 本文由「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 等场景全覆盖。