如何调试和测试 WebAssembly 代码才可靠？

调试和测试 WebAssembly 代码，关键是别把它当成一个黑盒二进制文件。Wasm 运行在 JS 宿主里，问题可能出在源语言逻辑、编译参数、JS 胶水代码、线性内存、浏览器兼容或构建产物加载上。可靠的流程通常分三步：先在源语言里测纯逻辑，再在 Wasm 环境里测导出接口，最后用浏览器 DevTools 和性能工具排查真实运行时问题。

开发阶段建议生成调试信息，不要一上来就用最大优化和压缩后的产物排错。Rust、C/C++、AssemblyScript 的参数不同，但目标一样：保留符号、生成 source map、能把浏览器里的调用栈映射回源码。生产构建再单独开启优化、裁剪和压缩。

bash
# Rust + wasm-pack，在浏览器环境跑测试
wasm-pack test --chrome --headless

# Emscripten 保留调试信息和 source map
emcc src/main.c -O0 -gsource-map -s WASM=1 -o dist/app.js

# 查看 wasm 结构，确认导出、导入和段信息
wasm-objdump -x dist/app.wasm

追问

Chrome DevTools 里看不到源码怎么办？

先确认构建时确实生成了调试信息和 source map，而且浏览器能通过正确路径加载到映射文件。很多问题不是 DevTools 不支持，而是打包器改了文件名、CDN 没上传 .map，或响应头禁止访问。还要注意优化级别，-O3 会内联和重排代码，断点可能跳来跳去，看起来像调试器坏了。排查逻辑问题时先用 -O0 或开发模式，确认问题后再切回 release 构建复测。

Wasm 单元测试应该放在源语言还是 JavaScript？

两边都要有，但关注点不同。源语言测试适合验证算法、边界条件和内部函数，比如 Rust 的 cargo test 可以在本地很快发现纯逻辑错误。JS 侧测试更适合验证 Wasm 导出接口、内存传参、异常转换和异步加载流程。取舍是源语言测试快而细，JS 集成测试慢但更贴近用户真实路径；只做其中一种都容易漏问题。

rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn add(a: i32, b: i32) -> i32 { a + b }

#[cfg(test)]
mod tests {
  use super::*;
  #[test]
  fn add_works() { assert_eq!(add(2, 3), 5); }
}

javascript
test('wasm add export works', async () => {
  const { instance } = await WebAssembly.instantiateStreaming(fetch('/app.wasm'));
  expect(instance.exports.add(2, 3)).toBe(5);
});

内存相关 Bug 怎么定位？

先把问题缩小到“读错了”“写越界了”还是“JS 视图失效了”。Wasm 线性内存本身不会像普通 JS 对象那样给你漂亮的错误提示，越界、编码长度不一致、释放后继续使用都可能表现成结果随机。调试时可以在 JS 侧打印指针、长度和关键字节，用 TextDecoder 检查字符串是否按预期写入。踩坑最多的是 memory.grow() 后旧 TypedArray 失效，所以每次扩容后都要重新创建视图。

javascript
let view = new Uint8Array(memory.buffer);
// memory.grow(1) 之后必须刷新
instance.exports.reserve_more();
view = new Uint8Array(memory.buffer);
console.log([...view.slice(ptr, ptr + len)]);

性能测试怎样避免测出假结论？

不要只测一次函数调用，也不要在开发构建里下结论。Wasm 有加载、编译、实例化和热身成本，短任务里这些成本会把计算收益盖住；长任务又要注意输入规模是否接近真实业务。比较 JS 和 Wasm 时，输入数据、内存布局、预热次数、浏览器版本都要一致。边界是性能优化必须绑定场景：如果瓶颈在网络、DOM 或主线程阻塞，换成 Wasm 也救不了。

CI 里怎么保证 Wasm 构建不会悄悄坏掉？

CI 至少要跑三类检查：源语言单测、Wasm 构建、宿主环境集成测试。还应该固定工具链版本，例如 Rust nightly、Emscripten SDK 或 wasm-pack 版本，否则一次升级可能改变导出名、优化行为或 polyfill。对二进制产物可以加 wasm-validate、导出接口快照和包体积阈值，防止无意中引入大依赖。取舍是检查越多越慢，可以把快速测试放到每次提交，浏览器矩阵和性能基准放到主分支或发布前。

bash
wasm-pack build --target web
wasm-validate pkg/app_bg.wasm
npm test
npm run test:e2e

调试 Wasm 不是找一个万能工具，而是把源代码、二进制、JS 宿主和浏览器运行时连成一条可观察链路。只要每一层都有测试和定位手段，Wasm 就不会是难以排查的黑盒。