dlopen失败主因是路径错误、依赖未解、权限或架构不匹配；须用绝对路径、检查文件存在性与位数一致性、配合dlerror调试。
Linux下用dlopen加载so文件，第一步不是写dlsym
很多新手一上来就急着找函数指针，结果dlopen返回nullptr还不知道为啥。核心问题是：路径不对、依赖没解、权限或架构不匹配。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先确认so文件存在且可读：
ls -l /path/to/libxxx.so，注意是否是64位程序加载32位so（会静默失败） -
dlopen传绝对路径最稳；若用相对路径，它按LD_LIBRARY_PATH、/etc/ld.so.cache、/lib、/usr/lib顺序找，不看当前目录 - 加
RTLD_NOW | RTLD_GLOBAL：前者让符号解析在dlopen时就报错（别等dlsym才崩），后者让后续dlopen的库能复用本库的符号 - 查错必接
dlerror()——dlopen失败后它才返回有意义字符串，且调一次就清空，别跳过
Windows下GetProcAddress找不到函数？十有八九是符号没导出
GetProcAddress只认DLL里真正“可见”的符号，C++类成员函数、未声明extern "C"的函数、或没加__declspec(dllexport)的函数，统统找不到。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- DLL源码里函数必须显式导出：
extern "C" __declspec(dllexport) int my_func(int x);——extern "C"禁用C++名字修饰，否则GetProcAddress("my_func")永远失败 - 用
dumpbin /exports my.dll（Windows）或nm -D libxxx.so（Linux）直接看符号表，确认函数名是否在列表里、有没有被修饰成_Z3funv这类 - 如果DLL是别人给的，且只有头文件，先检查头文件里是否有
__declspec(dllimport)宏定义，对应导入方式要匹配 - 函数名大小写敏感，Windows下也区分，别写成
My_Func去查my_func
跨平台封装时，dlsym和GetProcAddress返回类型不能直接当函数指针用
两者都返回void*，但C++标准禁止void*隐式转函数指针。直接强转在某些编译器（如Clang 15+）会报错，运行时也可能因ABI不一致崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须用函数指针类型显式转换：
auto func = reinterpret_cast<int>(dlsym(handle, "my_func"));</int> - 别用
typedef偷懒定义通用函数指针类型——不同函数参数个数/类型不同，类型安全全靠你手动对齐 - Linux下如果so用
-fPIC编译但主程序没开-rdynamic，某些全局符号可能无法被dlsym反向查到（少见但真实） - Windows下
HMODULE本质是void*，但别把它和void*混用——加载失败时是NULL，不是INVALID_HANDLE_VALUE
卸载动态库时，dlclose不是“必须调用”，但漏掉可能引发资源泄漏或重加载失败
dlclose减少引用计数，仅当计数归零才真正卸载。但如果你反复dlopen同一路径so，又不dlclose，进程里会堆积多个句柄，最终dlopen可能返回nullptr（Linux下常见于内存碎片或fd耗尽）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每个
dlopen成功后，确保有且仅有一次对应dlclose——别在异常分支遗漏，也别重复调用（dlclose后句柄失效，再调行为未定义） - Windows下
FreeLibrary同理，但要注意：DLL里若用了static局部对象或DllMain中执行清理，卸载时机不可控，尽量避免复杂析构逻辑 - 调试时用
lsof -p PID | grep .so（Linux）或Process Explorer（Windows）观察句柄是否持续增长，这是最直接的泄漏证据
最麻烦的其实是符号冲突：两个so导出同名函数，后加载的会覆盖前一个，而你完全感知不到——除非用LD_DEBUG=symbols或Dependency Walker深挖。这种问题往往压根不报错，只默默跑错结果。
