__cdecl 由调用者清理栈，__stdcall 由被调者清理栈；前者符号名如_foo，后者如_foo@8；二者 ABI 不兼容，混用导致栈失衡崩溃。
__stdcall 和 __cdecl 的核心 区别 在栈 清理责任方和参数压栈顺序，实际影响函数符号名、ABI 兼容性与跨语言调用。
谁负责清理栈？这是最直接的差异
调用约定本质是“调用者和被调用者之间关于栈怎么用”的协议。关键分歧点在于：函数返回后，谁来把传入的参数从栈上弹掉？
-
__cdecl：调用者（caller）负责清理栈。这意味着每个调用该函数的地方，编译器都要生成add esp, N（x86）或等效指令来回收参数空间。 -
__stdcall：被调用者（callee）负责清理栈。函数自身在ret时带立即数，如ret 8，一次性弹掉 8 字节 参数。
这导致同一函数在不同约定下生成的汇编不同，也决定了它们不能混用 —— 否则栈会失衡，轻则局部变量错乱，重则崩溃。
函数名修饰（name mangling）规则不同
为了防止链接时符号冲突，MSVC 对带调用约定的函数名做前缀 / 后缀修饰。这对 C++ 模板、extern "C" 和 DLL 导出尤其关键：
立即学习“C++ 免费学习笔记（深入）”；
-
int __cdecl foo(int a, char b)→ 符号名通常是_foo（前导下划线） -
int __stdcall foo(int a, char b)→ 符号名通常是_foo@8（@后跟参数总字节数）
如果你用 GetProcAddress 手动加载 DLL 中的函数，写错修饰名（比如该写 "_MyFunc@12" 却写了 "MyFunc"），就会返回 NULL —— 这是 Windows 平台 DLL 调用失败的常见原因。
参数压栈顺序相同，但 ABI 兼容性不互通
两者都采用从右到左压栈（push b; push a），所以单看参数布局没区别。但 ABI（应用二进制接口）不兼容：
- 你不能用
__cdecl声明去调用一个实际按__stdcall编译的函数（即使原型一致），因为调用方不会清理栈，而被调用方虽然清了，但调用方后续代码可能基于错误的栈顶位置读写。 - 反过来也不行：用
__stdcall声明调__cdecl函数，会导致被调函数自己清栈（清得少），而调用方又不补清，栈指针永久偏移。
典型场景：Windows API 函数（如 CreateWindowEx）全部是 __stdcall；而 C 标准库（printf, malloc）是 __cdecl。混用声明等于主动制造未定义行为。
现代开发中哪些地方还必须关心？
纯 C++ 项目里，除非对接特定系统层，一般不用显式写。但以下情况绕不开：
- 写 DLL 并导出函数给 C 或其他语言调用时，必须显式指定约定（常选
__stdcall以匹配 Windows API 风格）； - 用
typedef定义函数指针类型时，约定是类型的一部分：typedef int (__stdcall *PFN)(int);和int (__cdecl *PFN)(int)是不同类型，不可赋值； - 使用 MinGW 或 Clang 编译 Windows 程序时，
__stdcall可能默认不启用，需加-mstdps或确保头文件已正确定义。
最容易被忽略的是：头文件里声明了 __stdcall，但实现文件忘了加，或者 DLL 工程设置里调用约定不一致 —— 此时链接可能通过，运行时才崩，且难以定位。
