WebAssembly 从编译到运行会经历哪些步骤？

WebAssembly 从源码到浏览器运行，通常会经过四步：用 C/C++、Rust、Go 或 AssemblyScript 写核心逻辑；编译成 .wasm 二进制；在 JavaScript 中加载并实例化；最后通过导入导出函数完成调用。理解这条链路，比背 API 更有用，因为大多数问题都出在编译参数、加载方式和 JS/Wasm 边界设计上。

从源码到 wasm 文件

不同语言的入口不同。C/C++ 常用 Emscripten，Rust 常用 wasm-pack 或 wasm32-unknown-unknown target，Go 可以使用 GOOS=js GOARCH=wasm，AssemblyScript 则用 asc。编译器会把源代码变成 Wasm 指令、导出表、类型信息、内存声明等内容，有些工具还会生成一层 JavaScript glue code，帮你处理字符串、内存和模块初始化。

bash
# Rust 示例
rustup target add wasm32-unknown-unknown
cargo build --target wasm32-unknown-unknown --release

# C 示例
emcc add.c -O3 -s WASM=1 -o add.js

如果只是导出纯函数，产物可以很小；如果引入文件系统模拟、异常、运行时库，包体积会明显变大。生产环境需要检查生成物，不要把不需要的运行时能力一股脑带上线。

浏览器如何加载和实例化

JavaScript 侧常见加载方式有 WebAssembly.instantiate 和 WebAssembly.instantiateStreaming。前者先拿到 ArrayBuffer 再编译，兼容性和控制力更好；后者可以边下载边编译，适合服务器正确返回 application/wasm 的场景。

javascript
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('/pkg/add.wasm'),
  { env: { log: console.log } }
);
console.log(instance.exports.add(1, 2));

实例化时，宿主环境会准备导入函数、内存、表和全局变量。若 Wasm 需要调用 JS 提供的日志、时间、随机数或内存分配函数，导入对象必须和模块声明完全匹配，否则会在实例化阶段失败。

运行时的关键边界

实例化成功后，调用导出函数看起来像普通 JS 函数，但参数类型并不普通。Wasm 原生支持整数、浮点、引用等有限类型，复杂对象一般要通过线性内存传递。也就是说，add(1,2) 很简单，传一个 JSON 对象就需要序列化、写内存、传指针，再读取结果。

性能优化也主要围绕这条边界展开：减少小而频繁的跨边界调用，批量传数据，避免重复编译，给 .wasm 配好缓存。大型模块还要考虑懒加载，否则首屏会被初始化时间拖住。

部署阶段也属于运行流程的一部分。.wasm 文件最好走长期缓存，文件名带 hash，HTML 或 JS 入口只引用当前版本。服务器需要配置正确 MIME，否则流式编译会退化或失败。若模块较大，可以先渲染页面骨架，再在用户触发高性能功能时加载 Wasm，避免把所有成本压到首屏。

构建流程还要进入 CI。编译 Wasm 的工具链版本、Rust target、Emscripten 版本、wasm-opt 版本最好固定，否则同一份源码在不同机器上可能产出不同体积和性能。发布前应至少检查三件事：模块能否加载、导出函数是否符合包装层预期、核心路径性能有没有退化。这个检查比单纯确认文件存在更有价值。

追问

instantiate 和 instantiateStreaming 怎么选？

如果服务器能正确返回 Content-Type: application/wasm，优先用 instantiateStreaming，它可以下载时并行编译。若需要对字节做解密、校验、从 IndexedDB 读取，或者服务器 MIME 配错，就用 instantiate 更稳。取舍是流式加载快，但对部署要求更严格。常见坑是本地能跑，上 CDN 后 MIME 变成 application/octet-stream，流式实例化直接失败。

编译阶段的优化参数重要吗？

重要。-O3、wasm-opt、LTO、panic 策略、调试符号都会影响体积和运行性能。边界在于最高优化不总是最好，编译时间、调试体验和产物可读性都会变差。上线前应分别测冷启动、包体积和热路径耗时，而不是只看某个 benchmark。踩坑点是保留了大量调试符号，导致 Wasm 文件异常大。

JS 和 Wasm 之间传对象为什么麻烦？

Wasm 函数接口偏底层，复杂对象通常要编码成字节放进线性内存。这样做的好处是可控、跨语言，坏处是开发成本高，容易出现编码不一致和内存释放问题。若数据很小，直接用 JS 处理可能更划算。若数据很大，应把一批数据一次性传入 Wasm，避免每个字段都跨边界调用。

WebAssembly 模块每次都要重新编译吗？

浏览器通常会做内部缓存，但应用层仍应避免重复 fetch 和实例化。可以把模块初始化封装成单例 promise，多个调用共享同一个实例。边界是有些模块实例带内部状态，不适合全局复用。踩坑点是在 React 组件每次挂载时重新初始化 Wasm，页面看起来只是慢，根因却是重复编译和分配内存。

调试 Wasm 程序有哪些现实限制？

可以用 source map、浏览器 DevTools、日志导入函数和原语言工具链调试，但体验通常不如纯 JS。优化后的 Wasm 变量名、调用栈和源码位置可能不直观。取舍是开发环境保留调试信息，生产环境去掉调试符号并压缩。遇到崩溃时要先判断是实例化失败、内存越界、导入缺失，还是语言运行时自己的 panic。