__stdcall由被调用函数清理栈且不支持可变参数，__cdecl由调用方清理栈并支持可变参数；Windows API和回调函数必须用__stdcall，C标准库函数默认用__cdecl，约定不匹配会导致栈失衡、崩溃或链接失败。
__stdcall 和 __cdecl 是什么，什么时候必须选一个
它们是 Windows 平台上控制函数调用约定（calling convention）的关键字，直接影响栈清理责任归属和参数压栈顺序。你不是“想用才用”，而是**调用 Windows API 或写 DLL 导出函数时，几乎必然要匹配目标要求**——比如 WinMain 必须是 __stdcall，而普通 C++ 成员函数默认是 __thiscall，混用会导致栈失衡、崩溃或神秘的返回值错误。
__cdecl 是 C/C++ 默认，但 Windows API 不认它
绝大多数自由函数（如 printf、malloc）和你自己写的普通全局函数，默认就是 __cdecl：调用者负责清理栈，支持可变参数（...）。但 Windows 系统 DLL（如 user32.dll、kernel32.dll）导出的函数几乎全是 __stdcall。如果你直接声明：
typedef int (*FuncPtr)(int, char*); // 错！没指定调用约定
然后去 GetProcAddress 拿到函数指针并调用，大概率 crash——因为编译器按 __cdecl 生成调用代码，而实际函数期望自己清理栈。
- 正确写法必须显式标注：
typedef int (__stdcall *FuncPtr)(int, char*); - 声明 Win32 回调函数（如
WNDPROC）也必须用__stdcall，否则窗口过程一执行就崩 -
main函数不能加__cdecl（它本来就是），但加了也不报错；加__stdcall会链接失败（LNK2019）
__stdcall 的参数传递和栈行为细节
__stdcall 要求被调函数自己清理栈，参数从右向左压栈（这点和 __cdecl 相同），但**不支持可变参数**——所以你不能写 int __stdcall foo(int a, ...)，编译直接报错 C2729。
- 函数名修饰：MSVC 下
__stdcall会自动在函数名前加下划线、后加@N（N 是参数总字节数），例如MyFunc@8；__cdecl只加下划线_MyFunc。这影响GetProcAddress查找 - 导出 DLL 函数时，若用 .def 文件，需确保导出名与修饰名一致，或用
extern "C"+__declspec(dllexport)避免名字修饰 - x64 平台统一使用
__fastcall（实际是微软定义的 x64 调用约定），__stdcall和__cdecl在 64 位下被忽略（仅作语法兼容）
常见错误现象和排查线索
栈不平衡不会立刻报错，而是表现为：函数返回后局部变量乱码、后续函数调用参数错位、ESP 值异常、程序在无关代码处崩溃。调试时看反汇编最直接：
- 如果调用后没见
add esp, N（__cdecl特征），但被调函数结尾有ret N（__stdcall特征），说明约定不匹配 - VS 调试器里看“调用堆栈”是否突然中断、帧地址跳跃，往往就是调用约定错
- 用 Dependency Walker 或
dumpbin /exports查看 DLL 实际导出符号名，比对是否带@后缀
真正麻烦的是跨语言调用——比如 Python ctypes 加载 DLL，必须用 WINFUNCTYPE（对应 __stdcall）而非 CALLBACK（其实也是 __stdcall，但别被名字误导），否则照样崩。约定这事，差一个关键字，整个调用链就不可靠。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
