多数问题出在函数导出方式不匹配：c++默认name mangling导致getprocaddress找不到入口，必须用extern "c"或.def文件导出未修饰名，并确保编译未启用/gl优化。
Windows下用LoadLibrary加载DLL时找不到入口怎么办
多数问题出在函数导出方式不匹配。C++编译器默认对函数名做C++ name mangling，GetProcAddress按C风格符号名查找会失败。
- 必须在DLL中用
extern "C"声明导出函数，或在.def文件里显式导出未修饰名 - 确保DLL编译时未启用
/GL（全程序优化），否则可能被链接器内联掉导出函数 - 调用
LoadLibrary后立即检查返回值，NULL说明路径错误、依赖缺失或位数不匹配（32/64） - 用
GetLastError()辅助诊断，常见错误码：126（模块未找到）、193（不是有效Win32应用）
Linux下dlopen失败但dlerror返回空字符串
这通常意味着动态库已加载成功，但后续dlsym调用失败——dlerror只在最近一次dlopen/dlsym失败后才返回非空值，且调用一次就清空。
- 务必在每次
dlsym后立刻调用dlerror()，不能等到最后统一查 - SO文件需带
.so后缀，且dlopen传入的路径必须是绝对路径或LD_LIBRARY_PATH包含的相对路径 - C++符号仍需
extern "C"导出，否则dlsym查不到mangled后的函数名 - 编译SO时加
-fPIC -shared，主程序链接时不要加-rdynamic（它影响的是反向符号可见性，和dlopen无关）
跨平台封装时如何统一处理函数指针类型转换
Windows的FARPROC和Linux的void*本质都是地址，但C++标准禁止直接把void*转函数指针，gcc/clang会报错，MSVC默认允许但不安全。
- 用
reinterpret_cast强制转换，例如：auto func = reinterpret_cast<int>(dlsym(handle, "add"));</int> - 避免用
typedef定义通用函数指针类型再强转——类型擦除会导致调用时栈错乱 - 更稳妥的做法是：为每个要调用的函数单独声明原型，然后用
reinterpret_cast转成该具体类型 - 如果函数签名复杂（如含STL容器参数），放弃动态加载，改用纯C接口桥接
卸载DLL/SO后原生资源没释放导致内存泄漏
FreeLibrary和dlclose只是减少引用计数，只有计数归零才真正卸载。若DLL内部new了内存、打开了文件或创建了线程，不会自动清理。
- DLL/SO应提供显式的
cleanup()或shutdown()函数，并在FreeLibrary/dlclose前主动调用 - Windows下DLL可实现
DllMain的DLL_PROCESS_DETACH分支，但仅限于简单清理（不能调用LoadLibrary或同步I/O） - Linux下SO无等效机制，必须靠使用者约定调用清理函数
- 注意：
dlclose后再次dlopen同名SO，得到的是新句柄，旧函数指针不可再用
dlsym。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
