dlopen加载so失败主因是路径、依赖或权限问题：路径需绝对或ld_library_path包含；ldd查依赖缺失及glibc版本兼容性；检查文件可读及selinux/沙箱限制；确认架构匹配。
Linux 下用 dlopen 加载 so 文件失败的常见原因
直接调用 dlopen 返回 nullptr，十有八九不是代码写错了，而是路径、依赖或权限问题。
-
libxxx.so路径没写对：相对路径基于当前工作目录（getcwd），不是可执行文件所在目录；建议用绝对路径，或确保LD_LIBRARY_PATH包含目标目录 - so 文件本身依赖其他库未满足：运行
ldd /path/to/libxxx.so查看缺失项，尤其注意 glibc 版本兼容性（如编译用 GLIBC_2.34，运行环境只有 2.28 就会静默失败） - 权限问题：so 文件不可读（
chmod +r）、或 SELinux/Android 沙箱限制（后者需用android_dlopen_ext） - 架构不匹配：32 位程序加载 64 位 so，或 ARM64 程序加载 ARMv7 的库，
dlopen会直接返回空，错误信息藏在dlerror()里
Windows 上 LoadLibrary 找不到 DLL 的真实逻辑
它不只查传入路径，还按固定顺序搜索多个位置，这个顺序决定了“为什么明明放同目录却加载失败”。
- 如果传入的是不含路径的文件名（如
"mylib.dll"），会依次搜索：当前目录 →PATH环境变量中的目录 → Windows 系统目录（System32）→ 16 位系统目录 → 当前可执行文件所在目录（注意：这是最后才查的！） - 传入绝对路径（如
"C:\libs\mylib.dll"）则只查该路径，但要注意反斜杠需转义或用原始字符串（R"(C:libsmylib.dll)"） - 显式依赖的 DLL（比如你的 so/dll 内部又调用了另一个 dll）不会从你传入的路径继承搜索逻辑，它们走的是系统默认路径 —— 这就是为什么把所有 dll 放一起有时也不行
C++ 封装跨平台 dlopen/LoadLibrary 的最小安全实践
别自己写宏封装成一个“统一接口”，容易掩盖平台差异带来的行为偏差。真正要做的，是隔离加载逻辑，让符号获取和错误处理保持一致。
- 加载后必须立即检查：Linux 用
dlerror()（清空并取错），Windows 用GetLastError()，两者返回值语义不同，不能混用 - 获取函数指针时，Linux 用
dlsym，Windows 用GetProcAddress；二者都返回void*，强制转换为函数指针类型时，务必保证签名完全一致（参数个数、const、调用约定 —— Windows 上尤其注意__cdeclvs__stdcall） - 卸载时机要明确：Linux
dlclose不等于立即释放内存（引用计数机制），WindowsFreeLibrary成功后不能再调用其中任何函数，哪怕指针还存着
调试动态加载失败时最该先看的三件事
别急着翻文档，先确认这三个点，80% 的问题当场定位。
立即学习“C++免费学习笔记（深入）”；
- 用
file（Linux/macOS）或dumpbin /headers（Windows）确认 so/dll 的 ABI 架构和位数是否与主程序匹配 - Linux 下运行前加
LD_DEBUG=files,libs，Windows 下用Process Monitor过滤进程名 + “CreateFile”事件，看它到底尝试打开了哪些路径 - 检查符号可见性：Linux 编译 so 时若用了
-fvisibility=hidden，又没对目标函数加__attribute__((visibility("default")))，dlsym就一定找不到
跨平台动态加载真正的复杂点不在语法，而在每个平台对“依赖传递”“符号解析时机”“错误静默”的设计哲学完全不同。漏掉任意一层隐式行为，都会变成深夜对着空指针发呆。
