4.3 调试与性能分析

4.3 调试与性能分析

本节摘要：字节码上的调试曾是 Wasm 的短板——断点落在指令上、栈帧全是编号。如今调试信息与工具链已经补上了这条断层：浏览器可断在源码行，独立运行时可打出带符号的回溯。本节给出调试信息的原理与配置、两大环境的排查手法，以及一套完整的性能定位案例。

某团队的图像处理模块上线后收到用户反馈：偶发的锯齿伪影，复现率不到半成，日志里只有一条干瘪的"模块执行异常"。放在三年前，这类问题基本只能靠加日志硬磨；现在，一条完整的排查链路能在半天内走完。本节就沿这条链路，把调试与剖析的装备逐件点亮。

断层之源：字节码与源码之间隔着两层翻译

传统调试建立在"可执行文件带符号表"的默契上；Wasm 的调试要跨两层翻译——高级语言到字节、字节到机器码。前一章说过引擎分层编译：解释器与基线编译产生的代码没有源码概念，优化编译还会重排甚至内联函数。调试信息的作用就是在断层两端架桥：它记录"字节码偏移对应哪个源文件哪一行、哪个变量存在哪个栈槽"，调试器靠这张表把底层现场翻译回人话。

桥的建设从编译期开始。Emscripten 用 -g 参数保留调试信息，Rust 工程在发布构建里显式打开：

$ emcc img.c -O2 -g -o img.js          # -g 保留 DWARF 调试信息
$ cargo build --target wasm32-unknown-unknown --release
​

# Cargo.toml：发布构建保留调试信息（体积换可排查性，出问题再重编也行）
[profile.release]
debug = true
​

调试信息确实增重字节——发布包剥离、排查包保留，是常见的双产物策略。名字段（name section）是轻量替代：只保留函数与局部的名字、不带行号映射，体积代价小得多，wasm-opt 的 strip-debug 之外还有专门的保留选项，适合"只想要可读回溯"的场景。

浏览器侧：断点终于落在源码行上

现代浏览器开发者工具对 Wasm 的支持已与 JavaScript 几乎平权：源码面板里可以像打开 JS 文件一样打开原始源文件（借助调试信息），在任意行打断点、单步执行、查看局部变量；变量面板展示的是高级语言的变量名而不是栈槽编号。内存查看器能直接翻看线性内存的内容——按十六进制与 ASCII 双栏显示，配合第三章的布局知识，手工核对结构体字段不再是猜谜。

一个实用的排查习惯是把 JavaScript 断点与 Wasm 断点串成链：先在互调边界（JS 调用导出函数的那一行）断下，确认输入数据的内存视图正确，再步进进入 Wasm 侧。跨边界数据错误（布局不一致、字节序、忘记重建扩容后的视图）能在第一站现形，根本轮不到进模块内部找。

独立运行时侧：回溯要带符号

服务端的排查主角是日志与回溯。wasmtime 等运行时在陷阱发生时打印调用链，如果模块带名字段或调试信息，回溯里是函数名与源码位置，否则只有函数编号——后者可读性趋近于零：

$ wasmtime run --dir=. demo.wasm
thread panicked: wasm trap: wasm `unreachable` instruction executed
error while executing at wasm backtrace:
    0: 0x2f1c - demo.wasm!parse_header        # 带名字段：函数名可读
    1: 0x2e40 - demo.wasm!handle_request
    2: 0x2c98 - demo.wasm!main
​

静态体检工具同样常备：wasm-objdump 列出节与函数明细，wasm2wat 反汇编成可读文本，配合第二章的格式知识，多数"行为异常"能直接读出来。性能侧，独立运行时暴露原生性能计数器，火焰图工具可以按 Wasm 函数名聚合采样——浏览器与服务端的分析手段已经趋同：分层时间线找瓶颈段，火焰图找热点函数，计数器看内存与调用频次。

完整案例：把伪影问题查到底

回到开头的现场，把链路走完整。背景：图像处理模块偶发锯齿，仅在大图与多线程场景出现，常规测试环境复现不了。操作：用带调试信息的版本替换线上模块，在用户环境开启远端调试回传；同时用火焰图对比正常与异常请求的性能轮廓。回溯显示异常路径的最后调用是某个水平滤波函数，火焰图显示该函数的缓存命中比正常路径低得多——结合源码级单步，最终定位到一条按行拷贝的 memory.copy 调用：大图行宽超出一页容量的边界时，拷贝跨越了页边界而长度参数仍是按单页算的。结果：修正长度计算后，构造大图回归测试，伪影消失，多线程场景同步验证通过。解读：这类问题单靠日志永远找不到——错误本身不抛陷阱（越界长度恰好合法），只有"性能轮廓异常加源码级回溯"的组合能把嫌疑收敛到具体函数。调试信息与剖析工具的价值正在于此：把不可见的执行现场翻译成可推理的数据。变式：同类思路适用于所有"偶发且无陷阱"的问题——先比性能轮廓，再看回溯热点，最后源码单步；反过来，有陷阱的问题则直接从陷阱原因与回溯入手，不必绕道剖析。

本节要点回顾

• 调试信息的桥作用：DWARF 映射把字节偏移与栈槽翻译回源码行与变量名，是现代 Wasm 调试的地基；
• 发布与排查双产物：调试信息增重字节，剥离与保留按包分流，名字段是轻量折中；
• 浏览器侧已近平权：源码断点、单步、变量名、内存查看器，配互调边界断点是最高效的起点；
• 服务端看回溯与计数器：带符号回溯、火焰图、性能计数器构成排查铁三角；
• 无陷阱的偶发问题走剖析路线：性能轮廓对比加源码单步，比日志硬磨快一个量级。

排查工具速查卡

把本节的工具按"查什么用什么"收成一张速查卡，事故现场按图索骥：

这张卡的用法有个总原则：先分类再深入。加载失败类问题查格式与对账（第二章知识），执行期问题查陷阱与调用链（第三章知识），性能问题查轮廓与热点（本章方法）——三类问题三套工具，别混着用。

装备配齐，出港在即。下一章驶向第一座大码头：与 JavaScript 的互操作，把前四章的机械全部接到真实应用上。