LoadLibrary与dlopen核心差异在于错误处理、路径规则和后缀补全：前者失败返回NULL且无错误字符串，后者需dlerror()获取；前者自动加.dll，后者须显式指定.so/.dylib；路径分隔符及依赖搜索机制也各不相同。
LoadLibrary 和 dlopen 的行为差异必须先理清
Windows 的 LoadLibrary 返回 HMODULE（本质是 void*），Linux/macOS 的 dlopen 也返回 void*，但语义不同：前者加载失败返回 NULL，后者失败返回 NULL 且需调用 dlerror() 获取错误字符串。直接 typedef 一个统一句柄类型容易掩盖错误诊断能力。
-
LoadLibrary要求路径为 Windows 风格（支持\或/），dlopen对路径更宽松，但若传入相对路径，行为依赖RTLD_LOCAL/RTLD_GLOBAL和当前工作目录 - Windows 默认不搜索子目录，Linux 默认也不搜索，除非设置
LD_LIBRARY_PATH或在/etc/ld.so.conf中配置 -
LoadLibrary自动尝试添加.dll后缀；dlopen不补后缀，必须显式传入libxxx.so或libxxx.dylib
封装成统一接口时怎么处理符号获取
Windows 用 GetProcAddress，Linux/macOS 用 dlsym，二者参数顺序一致（句柄、符号名），返回值都是 void*，但符号命名规则不同：C++ 编译器会对函数名做 name mangling，除非用 extern "C" 导出。跨平台动态库必须导出 C 风格符号，否则 GetProcAddress 和 dlsym 都找不到。
- 导出函数声明必须加
extern "C"，例如：extern "C" { __declspec(dllexport) int add(int a, int b); } - Linux 下编译动态库需加
-fPIC -shared，Windows 下需加/DLL和导出定义（或使用__declspec(dllexport)） - macOS 的
dlopen默认不加载未签名的 dylib（macOS 10.15+），需临时关闭公证检查或签名，否则返回NULL且dlerror()报 “no suitable image found”
一个轻量级跨平台动态库加载器示例
不依赖 Boost 或 Qt，仅用标准头和条件编译。核心是抽象出 module_handle 类型和统一的 load/get_symbol/unload 接口：
#ifdef _WIN32
#include <windows.h>
using module_handle = HMODULE;
#define MODULE_EXT ".dll"
#else
#include <dlfcn.h>
using module_handle = void*;
#ifdef __APPLE__
#define MODULE_EXT ".dylib"
#else
#define MODULE_EXT ".so"
#endif
#endif
<p>struct dynamic_module {
module_handle handle = nullptr;</p><pre class="brush:php;toolbar:false;">bool load(const char* path) {
#ifdef _WIN32
handle = LoadLibraryA(path);
#else
handle = dlopen(path, RTLD_LAZY);
#endif
return handle != nullptr;
}
template<typename T>
T get_symbol(const char* name) const {
#ifdef _WIN32
return reinterpret_cast<T>(GetProcAddress(handle, name));
#else
return reinterpret_cast<T>(dlsym(handle, name));
#endif
}
void unload() {
if (handle) {
#ifdef _WIN32
FreeLibrary(handle);
#else
dlclose(handle);
#endif
handle = nullptr;
}
}};
立即学习“C++免费学习笔记（深入）”；
使用时注意：路径拼接需手动加 MODULE_EXT，不能依赖系统自动补全；get_symbol 返回的是函数指针，调用前务必判空。
最容易被忽略的错误点：路径、权限与符号可见性
不是所有“能编译通过”的动态库都能成功 load。常见卡点不在代码逻辑，而在环境细节：
- Linux 下
dlopen失败却没调用dlerror()—— 错误信息只保留最后一次调用结果，不查就永远不知道是“文件不存在”还是“依赖缺失” - Windows 上用 MinGW 编译的 DLL 可能依赖
libgcc_s_dw2-1.dll等运行时，而目标机器没装，LoadLibrary静默失败 - CMake 项目中未设置
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)，又没显式__declspec(dllexport)，导致导出表为空，GetProcAddress找不到任何符号 - macOS 上 dylib 的
@rpath设置错误，dlopen找得到主库，但加载其依赖时失败
跨平台动态库加载真正难的从来不是写那几行 #ifdef，而是让每个平台都按它自己的规则“乖乖交出符号”。路径、导出、依赖、权限，漏掉一环，handle 就是 nullptr。
