第一章 初验：Wasm 从哪里来，要到哪里去

第一章 · 初验：Wasm 从哪里来，要到哪里去

章节摘要：本章是全书的验关入口。我们沿一条时间线追这箱"字节集装箱"的出身——它从 JavaScript 性能焦虑中诞生，在浏览器大战的休战协议里成为标准，又借 WASI 之手驶出浏览器港口；随后拆解它的设计目标，看可移植、安全、高效、开放这四根承重柱如何在规范里落地；最后巡视它今天停靠的典型泊位。读完本章，你应当能向同事讲清 Wasm 是什么、不是什么、凭什么值得投入。

一条主线：一箱字节的出身调查

想象你是验关现场的新人，接手头批到港的货：先查这批货的来龙去脉，再核对它的申报规格，最后看它通常发往哪些口岸。本章就按这个顺序走。

故事的起点不在 Wasm，而在它之前的产品 asm.js。2013 年前后，Mozilla 的工程师们面对一个尴尬局面：浏览器只能跑 JavaScript，而 JavaScript 的数值计算慢得让游戏引擎、视频编辑这类重型应用望而却步。他们的对策颇具想象力——把 JavaScript 的一个子集规范化，强制所有变量带类型标注，让引擎能把这个子集编译成机器码。asm.js 确实快了起来，但路子绕：源码先编译成 C++ 再降级成 JS 文本，体积膨胀，解析耗时，优化上限也低。真正的转机出现在厂商之间的罕见共识上：四大浏览器的引擎团队坐到一起，决定直接定义一套可验证的二进制指令格式，跳过 JavaScript 这层"文本集装箱"，让高级语言编译器直接产出紧凑字节。2017 年，Wasm MVP（最小可用版本）在四大浏览器中同时落地；同年它成为 W3C 正式标准。此后故事的重心从"更快的网页"转向"更通用的运行时"：2019 年 WASI 揭幕，把系统能力抽象成可移植接口；多线程、SIMD、引用类型、垃圾回收等提案陆续定稿；组件模型把跨语言拼箱变成现实。今天再讲 Wasm 的出身，必须讲完整条线——它早已不只是浏览器的加速插件。

沿途站点：三节如何分工

本章设三节，对应验关的三个动作。

1.1 起源与发展历程——查出生证明。从 asm.js 的权衡、四大厂商的标准化博弈，讲到 WASI 与组件模型带来的场景外溢。这一节回答"它为什么长成今天这个样子"，是理解后续所有设计决策的背景板。

1.2 核心概念与设计目标——核对申报规格。Wasm 的每项设计都对应一条明确的工程诉求：模块是分发与验证的基本单位；线性内存与导入导出把边界画清楚；确定性执行让行为可复现；类型系统让验证在运行前完成。这一节同时吸收了"关键特性"的内容，把性能、安全、跨平台三张特性清单摊开对照。

1.3 典型应用场景——巡视目的地码头。Web 端的图形密集型应用、服务端的插件沙箱与边缘函数、客户端的跨平台内核，各自的选型理由与不划算之处都会摆到台面上。

拐点与结论

本章最重要的认知转折是：Wasm 的本质不是"让网页变快的补丁"，而是"给不受信任的字节发签证的机制"。性能是结果，可验证的安全与跨端一致才是原因。抓住这一点，后面章节里那些看似琐碎的规范细节——为什么函数必须带类型签名、为什么内存访问要经过边界检查、为什么导入必须显式声明——都会显出各自的必要性。

读完你应该

• 能复述 Wasm 从 asm.js 到组件模型的演化脉络，并指出每个阶段解决的核心矛盾；
• 能说出 MVP 类型系统的四个数值类型，以及它们对可验证性的意义；
• 能对照说明 Wasm 与 JavaScript、与 Docker 容器、与传统原生代码的边界——各自管什么、不管什么；
• 能针对"游戏移植""插件系统""边缘函数"三类需求，判断 Wasm 是否是合适的载体并给出理由；
• 能识别常见误读，例如"Wasm 会取代 JavaScript""Wasm 是新的 JVM"这类说法错在哪里。

下一章的接力

出身调查完毕，下一章开箱验货：二进制格式里每个节装着什么、WAT 文本如何与之对应、类型与内存如何声明。读完第二章，你将能亲手拆开一个真实的模块文件，对照字节逐节解读——那是从"听说过"到"看得懂"的门槛。