getmodulehandle + getprocaddress 是 windows 下唯一可靠的运行时符号解析方案，必须先获取模块句柄再查函数地址；手动解析 pe 导出表在 aslr、重定位等现代环境下极易失败。
GetModuleHandle + GetProcAddress 是唯一可行的运行时方案
Windows 下无法像 Linux 的 dlsym 那样直接从符号名反查地址，必须依赖系统 API。核心路径只有一条：先用 GetModuleHandle（或 LoadLibrary）拿到模块句柄，再用 GetProcAddress 查函数地址。绕过这组 API 的所有“手动解析 PE 导出表”方案，在 ASLR 启用、DLL 重定位、延迟加载等现代环境下极易崩溃或返回错误地址。
常见错误现象包括：GetProcAddress 返回 NULL（但 GetLastError 是 0）、调用后触发 ACCESS_VIOLATION、函数行为异常（如参数错位、栈被破坏）。根本原因往往是模块未真正加载、函数名拼写/大小写/修饰不匹配，或 DLL 被卸载后仍缓存了句柄。
- 若 DLL 已由主程序隐式链接（即链接时用了 .lib），优先用
GetModuleHandle(NULL)获取主模块句柄，而非重新LoadLibrary - 显式加载 DLL 时，务必检查
LoadLibrary返回值是否为NULL；失败时立即调用GetLastError()判断是路径错误、依赖缺失，还是架构不匹配（x86 DLL 被 x64 进程加载） - 函数名必须与 DLL 导出表中完全一致：C 函数用原始名（如
"Add"），C++ 成员函数需用 mangled 名（如"?Add@Calculator@@QAEHHH@Z"），除非 DLL 显式用extern "C"导出
导出函数名不匹配是最常踩的坑
Visual Studio 默认对 C++ 函数名做 name mangling，导致 GetProcAddress 查不到。即使你写了 __declspec(dllexport)，没加 extern "C" 就等于白导出。
使用场景决定导出方式：供 C 程序调用？必须用 extern "C"；供其他 C++ 模块调用且不介意 mangled 名？可保留，但必须用 dumpbin /exports your.dll 确认真实符号名——别信头文件里写的 void Add(int, int)。
-
dumpbin /exports math.dll输出中找 “ordinal” 列非 0、“name” 列有内容的行，那就是能用的符号名 - 若看到 “name” 为空但有 “forwarder” 字段（如
math.dll._Add@8），说明该符号被转发到另一个 DLL，GetProcAddress仍可查，但实际调用会跳转 - 使用
__declspec(dllexport)时，避免在头文件中同时写extern "C"和类定义——C 链接不支持类，会导致编译失败或导出失败
获取地址后调用前必须做强制类型转换
GetProcAddress 返回 FARPROC（即 void *），它不携带任何类型信息。直接调用会导致参数压栈错误、返回值解释错误，尤其在浮点、结构体、thiscall 成员函数等场景下必崩。
性能影响几乎为零，但类型安全全靠这一步。C++11 起推荐用 reinterpret_cast，比 C 风格强制转换更明确意图。
typedef int (*AddFunc)(int, int);
HMODULE hMod = LoadLibrary(L"calc.dll");
if (hMod) {
AddFunc pAdd = reinterpret_cast<addfunc>(GetProcAddress(hMod, "Add"));
if (pAdd) {
int result = pAdd(3, 5); // 安全调用
}
}</addfunc>
- 函数指针类型必须与导出函数的调用约定严格一致：C 默认
__cdecl，Windows API 多用__stdcall，成员函数是__thiscall（此时不能直接用GetProcAddress调用，需额外处理this指针） - 若 DLL 导出的是类工厂函数（如
ICalculator* CreateCalculator()），类型定义中必须包含完整类声明和虚函数表布局，否则reinterpret_cast后调用虚函数会访问非法内存 - 不要把
GetProcAddress结果存为全局void*变量反复用——DLL 卸载后该地址立即失效，下次调用就是野指针
ASLR 和热更新场景下地址可能随时失效
Windows 默认启用 ASLR，每次加载 DLL 的基址都不同，但同一进程内只要 DLL 不卸载，GetProcAddress 返回的地址就一直有效。真正危险的是动态卸载+重加载（比如插件热更新），此时旧函数指针立刻变成悬垂指针。
兼容性影响明显：Win10 1809+ 对某些系统 DLL 增加了导出随机化（Export Address Filtering），但普通第三方 DLL 不受影响；64 位系统上指针宽度变化也要求函数指针类型必须用 void* 或 uintptr_t 存储，不能用 int。
- 热更新逻辑中，必须在
FreeLibrary前确保所有线程已退出对该 DLL 函数的调用，否则卸载后仍执行旧代码会引发异常 - 调试时发现地址每次启动都变，不是 bug，是 ASLR 正常行为；若地址固定不变，反而要检查是否误关了 ASLR（
/DYNAMICBASE:NO链接选项） - 跨进程共享函数地址毫无意义——虚拟地址空间隔离，A 进程的地址在 B 进程里就是无效数字
函数符号解析本身不复杂，难的是在各种加载状态、导出配置、调用约定、生命周期管理之间保持一致性。最容易被忽略的其实是 DLL 卸载时机与函数指针生命周期的绑定关系——这没有编译器帮你检查，全靠设计时想清楚。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
