在 WebAssembly 的设计文档中，它被描述为「可移植的抽象结构化堆栈机」（portable abstract structured stack machine）。然而，这个描述掩盖了一个关键的实现细节：WebAssembly 实际上是「披着堆栈机外衣的寄存器机」，且缺乏传统编译器赖以优化寄存器使用的 liveness 分析机制。这一缺陷对编译器工程师来说意味深长 —— 它要求在代码生成阶段显式管理局部变量的生命周期，而非依赖运行时隐式的栈帧行为。
局部变量的生命周期困境
WebAssembly 的局部变量（locals）本质上是函数作用域内的可变存储单元。与传统堆栈机中操作数栈上的值不同，局部变量具有持久的函数级生命周期。当编译器将高级语言编译为 WebAssembly 时，每个局部变量都会被分配一个固定索引，在整个函数执行期间持续存在。这种设计虽然简化了二进制格式的解码，却从根本上破坏了编译器优化所需的两大支柱：静态单赋值形式（SSA）与 liveness 分析。
在典型的堆栈机模型中，栈上的值具有天然的作用域边界。当一条指令弹出操作数时，这些值在物理上已不再存在于栈顶，编译器的 liveness 分析几乎是自明的 —— 栈项在作为操作数被消费后即视为死亡。然而，WebAssembly 的局部变量没有这种隐式的生命周期标记。考虑以下场景：两个局部变量 %0 和 %1 被用于一次加法运算，但在加法之后它们是否仍被使用？编译器无法仅从 WebAssembly 字节码本身判断这一点。即使引入 SSA 形式，局部变量的可变性也意味着每次赋值都会创建新的版本，导致 SSA 转换变得复杂且不完整。
这一问题的实际影响体现在寄存器分配的各个环节。当编译器将 WebAssembly 编译为目标架构的机器码时，函数参数和局部变量通常被映射到物理寄存器或栈槽。关键问题在于：由于缺乏 liveness 信息，编译器必须假设每个局部变量在整个函数期间始终存活。这意味着用于局部变量的寄存器会被永久标记为「占用」状态，无法被其他临时值复用。即便某个局部变量在函数的某个代码区域完全未被使用，编译器也无法回收其对应的存储空间，造成显著的寄存器浪费。
与传统堆栈机的本质差异
传统堆栈机（如 Java 虚拟机 JVM 的早期版本）之所以能够实现高效的寄存器分配，很大程度上归功于操作数栈的隐式生命周期管理。在这类模型中，每条指令的消费行为是明确的：栈顶的一个或两个值被弹出后即死亡，后续指令可以自然地复用这些栈槽。编译器可以在线性扫描代码时维护活跃变量集合，无需复杂的数据流分析。
WebAssembly 的设计则要求显式的局部变量管理。函数参数通过局部变量索引传递，循环计数器需要通过局部变量维护，甚至块（block）之间的数据传递也必须借助局部变量作为中介。以一个简单的例子说明：假设一个函数需要先执行加法，然后将结果传递给一个块进行处理。在纯堆栈机中，加法的结果自然地留在栈顶，块可以直接消费；但在 WebAssembly 中，必须先将结果存入局部变量，再从局部变量读取：
(func (result i32)
(local i32)
(local.set 0 (add (i32.const 1) (i32.const 2)))
(block (result i32)
(local.get 0)
)
)
这种模式强制编译器处理局部变量的读写开销，同时也使得原本简洁的数据流变得迂回。更重要的是，它将优化决策从运行时栈机制推向了编译时的显式管理，编译器现在必须自行推断何时可以安全地重用局部变量的存储空间。
工程实践中的参数与策略
对于构建 WebAssembly 编译器的团队，以下参数和监控点可作为工程实践的参考基准。首先，在 liveness 分析层面，建议实现基于逆向数据流的标准 liveness 分析算法：为每个 WebAssembly 基本块计算 live-in 和 live-out 集合，通过不动点迭代传播这些信息直至收敛。对于控制流图中的每个局部变量，当其不在某基本块的 live-out 集合中时，可以安全地将其标记为该块内的死代码或潜在的重用候选。
在寄存器分配策略上，可以采用局部重用的思路：如果某个局部变量在代码的关键路径上不再活跃，而同时存在其他临时值需要存储空间，编译器可以将两者映射到相同的局部变量索引，前提是它们的活跃区间不重叠。具体的活跃区间重叠检测可以通过区间相交算法实现：计算每个局部变量的定义点和使用点的区间，若两个区间不相交则可以共享存储。实践中，建议设置一个阈值参数 —— 例如当活跃局部变量数量超过可用「虚拟寄存器」数量的 80% 时触发溢出策略，将部分局部变量 spill 到线性内存中。
对于流式编译场景（streaming compiler），如 Firefox 的 Baseline 编译器，流式处理的限制使得完整的 liveness 分析代价高昂。建议采用保守策略：为所有函数参数和被显式引用的局部变量保留存储空间，同时在基本块边界处进行轻量级的活跃性预估。若要进一步优化，可考虑在 WebAssembly 模块中嵌入基本的 liveness 元数据（类似 WebAssembly 提案中的 name section 扩展），帮助下游编译器减少重复分析。
面向未来的语言演进
值得注意的是，WebAssembly 社区已经意识到这一问题并提出了相应的解决方案。多值（multi-value）提案允许函数和块具有参数以及多个返回值，从而可以在理论上完全消除局部变量的必要性。循环计数器可以通过块参数传递，函数调用结果的传递也不再依赖局部变量的中转。这种设计天然地符合 SSA 形式的约束 —— 值在定义后不可变，且通过参数传递明确数据流，消解了 liveness 分析的结构性障碍。
对于现有 WebAssembly 模块的优化，编译器工程师需要在保持二进制兼容性的前提下，手动重建 liveness 信息。这本质上是一种「事倍功半」的工作 —— 原始编译器已经完成了一次 liveness 分析并生成了 WebAssembly，优化编译器却需要重新推断这些信息。理解这一缺口是正确设计 WebAssembly 后端的关键第一步。
参考资料
- WebAssembly Troubles part 1: WebAssembly Is Not a Stack Machine — http://troubles.md/posts/wasm-is-not-a-stack-machine/