WebAssembly 模块检查器

使用方法

1. 把 .wasm 文件拖到方框里，或点击方框选择文件。文件只在页面内读取，不会上传。
2. 先看段落表：它给出每个段的字节大小和占整个文件的比例，这就是「这个模块为什么有三兆」的答案。
3. 把导入列表当作宿主必须履行的契约，逐项核对模块名、字段名、种类和确切的签名。
4. 把导出列表当作可以从 JavaScript 调用的接口，参数和返回类型直接取自模块自己的 type 段。
5. 在内存面板查看初始页数和最大页数（一页为 65,536 字节），并在自定义段里看看是否还保留着 name 或 producers 段。

常见问题

我的 .wasm 文件为什么这么大？

先看段落表。在常见的 Rust 或 C 构建里，code 段占文件的 70% 到 90%，这时唯一诚实的办法是减少代码：减少泛型实例化、去掉 panic 消息的格式化、跑一遍 wasm-opt -Oz。但构成常常出人意料。Go 会把运行时的静态数据编译进来，所以 data 段很大；内嵌文件的 emscripten 构建以数据为主；保留了 DWARF 调试信息的构建则把体积放在 .debug_info 一类的自定义段里，这些段在运行时完全用不到，正是 wasm-strip 会删掉的部分。

内存显示为「17..∞ 页」是什么意思？

WebAssembly 的内存以 65,536 字节为一页计算，初始 17 页意味着实例化的那一刻就占用约 1.1 MB。第二个数字是声明的上限；没有上限时，模块可以增长到宿主允许的最大值，在 32 位 WebAssembly 中是 65,536 页，也就是 4 GiB。声明了上限并不代表节省内存，它只是宿主可以提前预留地址空间的天花板。配合线程使用的共享内存是唯一必须声明上限的情况。

为什么导入和导出的名字全是 a、b、c？

这是开启了优化和 Closure 的 emscripten 输出。导入名和导出名在二进制里是字符串，缩短它们能减小文件，随附的 JavaScript 胶水代码也会同样压缩。运行时没有任何损失，但二进制本身就读不懂了。把函数索引映射回源码名字的 name 自定义段会在同一步被删除。它若还在，本工具会解码；若不在，producers 段往往是唯一能说明文件出自哪条工具链的线索。

模块导入了 env 和 wasi_snapshot_preview1，我需要提供什么？

每一条导入都是宿主对象必须按模块名和字段名填上的位置，引擎在实例化时还会检查类型。env 是 emscripten 汇集 C 运行时回调的命名空间；wasi_snapshot_preview1 说明模块是针对 WASI 构建的，在浏览器里需要一层 WASI 垫片；gojs 是 Go 运行时的桥；而 ./xxx_bg.js 这样的路径表示 wasm-bindgen 在等待它生成的胶水模块。只要缺少一项或参数个数不符，WebAssembly.instantiate 就会抛出点名的 LinkError。

它会运行或反汇编模块吗？

都不会。它只解析模块的声明：段、类型、导入、导出、限制、start 函数索引和自定义段。函数体只统计数量和总大小，指令从不解码，也不会创建任何引擎，因此即使是恶意模块在这里也什么都做不了。代价是行为不可见：无法知道某个函数在算什么、哪些导入真的会被调用、模块运行时究竟用掉多少内存，也无法知道函数体里是否含有类型上看不出来的 SIMD 或原子指令。

既然不读代码，怎么能说模块用了引用类型或多返回值？

因为部分 MVP 之后的提案改变的是编码本身的形状，而不只是指令集。返回值多于一个的函数类型就是多返回值；签名里的 externref 或第二张表就是引用类型；内存限制标志的第三个比特是线程所需的共享位；data count 段以及被动而非主动的段只存在于批量内存提案中；签名里的 v128 则是 SIMD。这里只声明字节能够证明的部分，只在函数体里以操作码形式出现的特性一概不作断言，所以这份清单可能比模块实际用到的特性更短。

相关工具