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年走向生产可用 |
| 适合人群 | 后端工程师、云原生/平台工程从业者、对软件架构演进感兴趣的开发者 |
要听懂这句话，得先回到 Docker 解决的那个核心痛点。在容器出现之前，软件交付是一场灾难：开发者在自己机器上跑得好好的程序，到了服务器上就因为库版本、操作系统差异、依赖冲突而崩溃——这就是臭名昭著的 "works on my machine"（在我机器上能跑）问题。Docker 的天才之处在于：把应用连同它所有依赖，一起塞进一个隔离的 Linux 命名空间和 cgroup 里，打成一个镜像，于是"构建一次，到处运行"终于大规模兑现了。
但 Solomon Hykes 的潜台词很尖锐：容器本质上是一种打补丁式的方案。它依赖宿主机内核，强绑定了 Linux 这套 syscall 体系，隔离边界是操作系统级别的，安全性靠的是"你只能调用我没禁止的东西"（黑名单模型）。如果有一种技术，从设计第一天起就内置了真正的沙箱、跨平台字节码和精细的能力授权，那么容器这套复杂的基础设施很多根本不需要存在。视频强调：Solomon 说这句话时，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 会说"如果它早存在"——容器某种程度上是在用操作系统机制，去笨拙地模拟一个本该由语言运行时完成的工作。（这部分是行业共识，视频做了通俗化讲解。）
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 这把"钥匙"终于打磨得可以真正开锁了。
如果说 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 作为底层运行时。
讲到这里，你可能会觉得 Docker 完蛋了——但视频和我都要泼一盆冷水："取代"这个词过于绝对，更准确的描述是"分层共存"。 WASM 目前还有几道硬伤：第一，GPU 支持和重计算场景偏弱，做机器学习推理、视频转码这类任务时，WASM 还难以媲美原生 CUDA；第二，工具链和生态成熟度远不及 Docker，Docker/Kubernetes 背后是十年沉淀的 Helm、Istio、可观测性全家桶；第三，长驻服务、有状态的复杂应用，容器依然是更现实的选择。
所以更可能的结局是：未来不是一个吃掉另一个，而是各管一段。 长驻的、重负载的、需要 GPU 和完整 OS 能力的后端服务继续跑在容器里；而短生命周期的、边缘的、对冷启动和安全敏感的工作负载——函数计算、插件系统、第三方扩展、跨平台 CLI 工具、浏览器内重计算——会越来越多迁移到 WASM。Solomon Hykes 的"预言"不会以"Docker 消亡"的方式实现，而会以"WASM 吃掉容器最不舒服的那一层市场"的方式逐步兑现。这才是 2026 年值得每个架构师关注的真实图景。
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 规范<br/>2026-06-13 发布] --> C
L[Solomon Hykes 2019 推文<br/>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，理解组件接口怎么定义、怎么跨语言调用，这笔投资在未来会回报得很丰厚。
Docker 容器是操作系统层面的"补丁"，而 WebAssembly 是从字节码层面重新发明的软件运行时——它不会消灭 Docker，但会吃掉容器最不舒服的那一层未来。
本文由「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 等场景全覆盖。