在 x64 架构上编写底层代码或实现 FFI（外部函数接口）时，一个常见的误区是认为「只要函数不使用某个参数，就可以不传递它」。这种认知忽视了调用约定（Calling Convention）的强制约束，可能导致隐蔽的栈帧破坏和未定义行为。本文以 Windows x64 调用约定为主线，结合 Linux x64 ABI 的共性规则，系统分析传递不足寄存器参数时的破坏机制，并为工程实践提供可落地的参数建议。
x64 调用约定的基础约束
现代 x64 调用约定采用混合传递模式：前四个整数或指针参数通过寄存器传递，额外参数则压入栈空间。在 Windows x64 体系中，参数依次映射至 RCX、RDX、R8、R9 四个寄存器；Linux x64 则使用 RDI、RSI、RDX、RCX、R8、R9。两种约定均要求调用者在栈上预留 32 字节的「影子空间」（Shadow Space），供被调用函数保存寄存器值之用。这一设计使得被调用函数可以确信地假设前四个参数槽位始终可用，即使这些参数在实际函数体内从未被引用。
问题的根源在于：被调用函数有权将预期参数所在的位置视为合法存储空间。编译器在生成代码时，会将这些槽位当作「已经分配的内存」进行复用 —— 将它们当作临时寄存器（spill slot）来存储函数内部的局部变量。这意味着，如果调用者没有按照函数签名完整传递参数，被调用函数仍会按照约定访问那些本应存在但实际缺失的内存位置，从而破坏调用者的栈帧结构。
栈帧破坏的具体机制
当调用者传递的参数数量少于函数签名要求时，主要面临两类破坏风险。第一类是栈空间错位风险：如果被调用函数期望一个栈参数但调用者未将其压栈，被调用函数仍会访问该栈位置，将其作为 scratch space 使用。在 callee-clean 调用约定下（例如 Microsoft x64），被调用函数负责清理栈空间，参数数量的不匹配会导致栈指针恢复错误，形成永久性的栈不平衡。这种错误往往不会立即触发崩溃，而是表现为随机的内存数据损坏，极难调试。
第二类是寄存器值污染风险。在寄存器传递模式下，如果某个参数对应的寄存器未被赋值，被调用函数读取到的是该寄存器中的随机残留值。然而，更危险的情况出现在编译器优化场景中：编译器可能发现函数内部某些分支不需要使用某个参数，于是将该参数槽位重新用于存储其他变量。调用者以为「未使用的参数」其实已被函数悄悄占用，对其写入操作会直接覆盖调用者栈帧中的有效数据。
一个经典的案例能够说明这种破坏的隐蔽性。考虑如下 C 函数：
int example(int a, int b) {
if (a <= 0) {
int c = compute_a();
process(a);
return c;
} else {
return compute_b(a, b);
}
}
编译器可能将变量 c 优化为直接复用参数 b 的存储位置，因为当 a <= 0 时参数 b 已经是「死变量」。如果调用者仅传递一个参数而省略 b，函数内部对 c 的写入操作会覆盖调用者栈帧中的其他数据，而这种破坏看起来像是随机的栈损坏而非明显的参数错误。
未定义行为的本质与风险边界
从语言标准的角度看，C 和 C++ 均将调用函数时参数数量不匹配的行为定义为未定义行为（Undefined Behavior）。这意味着程序的行为不受任何约束，编译器可以产生任意代码，甚至完全忽略参数传递错误。这不是一句空洞的法律声明，而是有具体工程后果的约束：在未定义行为框架下，编译器可以自由假设「调用者总是正确传递所有参数」，进而生成依赖这一假设的代码。一旦假设被打破，程序行为将完全不可预测。
在实际工程中，未定义行为的风险边界值得特别关注。一种常见的侥幸心理是：「这个函数在特定分支下不使用第二个参数，所以我可以不传。」这种做法在单次调用、静态链接且不开启优化的情况下可能「碰巧」工作，但一旦开启编译器优化、更换目标平台或与不同版本的库链接，行为立刻可能改变。更危险的是，这类错误往往在生产环境中以难以复现的内存破坏形式出现，传统的单元测试难以覆盖所有代码路径的组合。
工程实践中的防护策略
针对 x64 ABI 参数传递违规问题，工程实践可以从以下三个维度建立防护机制。首先是编译期检查：在 C/C++ 项目中启用编译器警告（如 GCC/Clang 的 -Wmissing-field-initializers 和 MSVC 的 /W4），并强制要求函数声明与定义严格匹配。对于使用函数指针或手动构造调用帧的场景，建议通过静态分析工具（如 Clang-Tidy 的 bugprone-* 检查项）扫描潜在的不匹配调用。
其次是运行时验证：在调试构建中，可以在函数入口添加参数完整性检查。例如，通过断言验证影子空间是否被正确分配、寄存器值是否符合预期范围。虽然这会引入性能开销，但对于底层库和 FFI 边界处的代码，这种防御性编程可以提前暴露问题。
最后是测试策略：对涉及汇编代码、手动 thunk 构造或跨语言调用的关键路径编写专项测试。测试应覆盖参数数量变化的边界情况，验证在不同优化级别（-O0、-O2、-O3）下的行为一致性。对于跨平台项目，尤其要注意 Windows 和 Linux 的调用约定差异 —— 前者要求影子空间，后者要求栈对齐（16 字节倍数），两者不可混用。
综上所述，x64 调用约定中的参数传递不是可选项而是强制性合约。传递不足的寄存器参数会触发栈帧破坏、未定义行为和难以追踪的内存损坏，这些后果在优化构建和特定执行路径下尤为隐蔽。工程实践中的最佳策略是依赖编译器的类型检查和静态分析工具，从源头消除参数不匹配的调用，并在 FFI 边界处实施防御性验证。
资料来源：本文核心细节来自 Microsoft DevBlogs The Old New Thing 栏目对 x64 调用约定违规后果的分析，以及 Microsoft Learn 官方文档对 x64 调用约定的规范说明。