WebAssembly 完全教程：浏览器中的接近原生性能
WebAssembly 从零到精，涵盖 WASM 起源、目标语言、与 JS 互通、性能对标、实战场景与限制，理解浏览器中的可执行二进制代码。
长期以来，JavaScript 是浏览器唯一的编程语言。但 JavaScript 的动态特性和垃圾回收虽然提升了开发效率，却无法达到 C、C++ 甚至 Rust 那样的原生性能。WebAssembly（WASM）的诞生打破了这一僵局。2017 年，W3C 正式发布 WebAssembly 规范，一种编译到二进制格式的字节码，在浏览器中以接近原生的速度执行。从此，任何能编译到 WASM 的语言（C/C++/Rust/Go）都能在浏览器中跑。图像处理、游戏引擎、密码学计算、甚至整个 IDE 都来到了浏览器。本教程从 WASM 的起源讲起，深入理解它与 JavaScript 的互通方式、性能特点、应用场景与现存限制。
WASM 的起源与目标
2015 年，asm.js 出现了——一个 JavaScript 的受限子集，看起来像普通 JS 但能被浏览器编译成机器码。通过"强制转整型"的惯用法，引擎知道这是类型化代码，可以优化。但 asm.js 毕竟是 JavaScript，文件大、加载慢。
2017 年，WebAssembly 应运而生。它是一种真正的编译目标——二进制格式，无需边加载边解析，直接编译成机器指令。同时 WASM 还是可移植的，一份 .wasm 文件可以在任何支持 WASM 的环境运行。
WASM 的设计目标很明确：提供一个安全、高效的执行环境，让已有的 C/C++/Rust 代码库能直接在浏览器中运行，性能接近原生。
目标语言：C/C++/Rust/Go/AssemblyScript
C/C++ 通过 Emscripten 编译到 WASM。大量老牌库都这样移植了：SDL、SQLite、OpenSSL、ImageMagick。优点是代码改动少；缺点是编译工具链复杂，体积较大。
Rust 对 WASM 支持最好。Rust 本身就强调安全和性能，WASM 天然适合。体积小、性能好，是新项目首选。
Go 从 1.11 开始支持 WASM 编译。代码改动最少，部分标准库可用。但 Go 的垃圾回收器为浏览器优化不足，生成的 WASM 体积较大。
AssemblyScript 是 TypeScript 的 WASM 方言，直接编译到 WASM。开发体验最好，性能也不错。适合新项目。
WASM 与 JavaScript 的互通机制
WASM 模块不能自己做任何事。它需要一个主机环境（浏览器）提供内存、导入函数等。这叫模块实例化。
JavaScript 侧调用 WASM 函数的流程：加载 WASM → 编译（可选）→ 调用导出函数。但这里有个问题：WASM 和 JS 数据类型不完全匹配。WASM 只支持 i32、i64、f32、f64 四种基础类型。
共享内存的方式：使用 ArrayBuffer。WASM 模块有一个线性内存（看起来是一个大字节数组），JavaScript 可以创建同一块 ArrayBuffer 的不同视图。WASM 在这块内存中读写数据，JavaScript 从外部读取。这样避免了数据拷贝。
性能：接近原生的 60-90%
实际基准测试（由 Mozilla、Google、Rust 社区发布）：
• 整数运算：WASM 达到原生的 95%；\n• 浮点数学：WASM 达到 90-100%；\n• 内存操作：WASM 达到 95%+；\n• 函数调用开销：WASM 和原生一样高效；\n• 垃圾回收：WASM 默认无 GC，更高效。
与 JavaScript 对比：同一个算法，JavaScript 通常慢 10-100 倍，取决于算法复杂度和 V8 优化程度。
结论：如果你的 JavaScript 代码跑得很慢，迁移 WASM 可能得到 10 倍加速。但如果 JavaScript 本身不是瓶颈，WASM 帮助不大。
应用场景：图像、游戏、加密、编解码
图像处理 是 WASM 的最佳舞台。ImageMagick.wasm、OpenCV.wasm 比 JavaScript 快 50-100 倍。
游戏引擎 是另一大应用。Unity WebGL 可以在浏览器跑中等规模游戏。虽然体积大、加载慢，但运行时帧率稳定。
密码学与数据加密：libsodium.wasm、TweetNaCl.wasm 在浏览器提供端到端加密。
视频/音频编解码：FFmpeg.wasm 可以在浏览器转码视频。
数据分析与科学计算：TensorFlow.js（部分 ops 用 WASM 加速）都用上了 WASM。
WASM 的限制与 WASI 的未来
无法直接访问 DOM。WASM 是沙箱，无法操作网页元素。必须通过 JavaScript 桥接。
单线程。WASM 本身没有多线程（Worker）。虽然可以用 Web Workers 跑多个 WASM 实例来模拟多线程，但共享内存和同步开销大。
垃圾回收 支持仍在实验中。当前 WASM 主要是手动内存管理。
WASI（WebAssembly System Interface）是 WASM 的服务端方向。定义了如何在非浏览器环境安全访问文件系统、网络、进程等。WASI 的未来可能比浏览器 WASM 更大。
开发工具与最佳实践
编译工具链：C/C++ 用 Emscripten，Rust 用 wasm-pack（官方推荐）。两者都有很好的文档和社区。
调试：Chrome DevTools 支持 WASM 源代码映射，可以调试原始 Rust/C 代码。
体积优化：用 wasm-opt（Binaryen 工具）压缩和优化字节码；去掉不用的导出和类型信息；用 gzip 压缩。
加载策略：初始化不需要 WASM 也能展示页面；用 Service Worker 缓存 WASM 文件；如果 WASM 文件很大，在后台加载。
WASM 的未来：GC、多线程、异步
W3C 正在制定多个扩展提案：
Reference Types & GC：允许 WASM 管理 JavaScript 对象的引用，也让 Python/Java 这样的 GC 语言编译到 WASM 时可以用内置 GC。
Threads：将 SharedArrayBuffer 和多线程 WASM 纳入规范。
异步 I/O：Asyncify 允许 C 代码在遇到 I/O 时暂停，让 JavaScript 处理，之后恢复。
预期 2-3 年内，WASM 会支持更多类 JavaScript 的便利特性，同时保持性能优势。
常见问题
为什么需要 WASM，不用 JavaScript 不行吗？
适合。但如果需要高性能或重算法逻辑，JavaScript 的动态类型和垃圾回收会带来开销。WASM 是静态类型和手动内存管理，接近原生 C/Rust 的性能。例如图像处理中，相同算法 WASM 可能比 JS 快 10-100 倍。选型标准：算法简单、UI 为主 → JavaScript 足够；数据密集、计算密集 → WASM 值得。
WASM 能直接操作 DOM 吗？
不能。WASM 没有直接的 DOM API。必须通过 JavaScript 桥接：WASM 调用 JavaScript 函数，函数操作 DOM。这种 FFI 有调用开销，但对于大部分应用（计算密集）来说，DOM 操作占比很小，性能影响微乎其微。如果应用以 DOM 更新为主，WASM 收益不大。
WASM 文件大小和加载时间如何？
WASM 二进制体积通常比等价的 JavaScript 小 3-10 倍。例如一个 1MB 的 WASM 模块可能用 JavaScript 写需要 3-10MB。加载时间包括：下载（网络）+ 解析（几十到几百毫秒）+ 实例化。大多数情况下，下载是瓶颈，不是解析。WASM 的优势是编译速度快、可流式加载。
Unity 和 Unreal 的 WASM 版本好用吗？
Unity for WebGL（官方，成熟）用 IL2CPP 转译 C# 到 C++，再编译到 WASM。可以直接用 Unity 编辑器开发游戏，输出 Web 版本。缺点是包体庞大（通常 50-200MB）、加载慢、不支持多线程。Unreal 5 的 WebGL 支持在改善中，但还不如 Unity 成熟。对于 2D 或中等 3D 游戏，效果可以；大型 AAA 游戏仍需客户端。
WASM 的安全性如何？会被逆向工程吗？
WASM 的安全模型是沙箱运行，无法直接访问宿主系统（除非通过 API 桥接）。但 WASM 二进制可以被反汇编回接近源码的形式。如果代码中有算法秘密（例如加密密钥），不应放在浏览器侧 WASM，而是后端。WASM 更适合做算法逻辑（图像处理、数据分析），而不是安全敏感的代码。