不能直接用dlopen或loadlibrary因行为差异大：dlopen默认不加载依赖，loadlibrary自动递归加载；调用约定不匹配会导致栈错乱；跨平台需统一语义与生命周期管理。
为什么不能直接用 dlopen 或 LoadLibrary
因为二者行为差异太大：dlopen 默认不加载依赖（除非传 RTLD_GLOBAL），而 LoadLibrary 会自动递归加载所有依赖 DLL；dlsym 返回 void*，GetProcAddress 也返回 FARPROC，但 Windows 下函数调用约定（__cdecl/__stdcall）必须和符号声明严格一致，否则栈会错乱。跨平台封装第一关不是写代码，是统一语义——比如“打开失败时是否尝试加载同名 .dll/.so/.dylib”、“是否自动搜索 PATH / LD_LIBRARY_PATH / DYLD_LIBRARY_PATH”。
如何设计统一的加载接口
核心是抽象出三个操作：打开、查找符号、关闭。不要暴露平台原生句柄（void* 或 HMODULE），而是用一个轻量结构体包装，并在构造时记录平台类型：
struct Library {
enum class Kind { Unknown, Dl, Win, Dyld };
Kind kind;
union {
void* dl_handle;
HMODULE win_handle;
void* dyld_handle;
};
Library(const char* path);
~Library();
template<typename T> T symbol(const char* name);
bool valid() const;
};关键点：
-
Library构造函数需按顺序尝试path、path + ".so"（Linux）、path + ".dll"（Windows）、path + ".dylib"（macOS），避免用户拼错后缀 - Windows 下必须调用
SetDllDirectoryA("")或用LOAD_LIBRARY_SEARCH_APPLICATION_DIR（Win10+），否则LoadLibrary可能从系统目录误加载旧版 DLL - macOS 需要
setenv("DYLD_LIBRARY_PATH", ...)仅影响后续加载，对已运行进程无效；更可靠的是用NSAddImage或改用dlopen（macOS 10.15+ 支持RTLD_LOCAL等标准 flag）
符号获取时最容易崩的几个坑
最常见崩溃不是找不到符号，而是类型擦除后强制转函数指针时调用约定/参数尺寸不匹配。例如：
立即学习“C++免费学习笔记（深入）”；
- Windows 上 C++ 成员函数导出需声明为
extern "C" __declspec(dllexport)，否则名字被 mangling，GetProcAddress查不到 - Linux 下若 so 编译时用了
-fvisibility=hidden，必须对要导出的函数加__attribute__((visibility("default"))) - macOS 的
dlsym在RTLD_DEFAULT下可查到主程序符号，但 Windows 的GetProcAddress对 EXE 中的符号必须用GetModuleHandle(NULL)显式获取模块句柄 - 模板函数无法直接导出，必须显式实例化并加导出声明
所以 symbol() 模板内部应做运行时检查：Windows 下先用 GetLastError() 判断是否为 ERROR_PROC_NOT_FOUND，Linux/macOS 下检查 dlerror() 是否非空，而不是只靠返回值判空。
资源清理和线程安全怎么处理
dlclose 和 FreeLibrary 都不是完全等价的：dlclose 是引用计数型，多次 dlopen 同一路径只会增计数，dlclose 减到 0 才真正卸载；FreeLibrary 是立即释放，且如果 DLL 内有线程局部存储（TLS）或 DllMain 中执行了清理逻辑，卸载时机很关键。
- 封装层不应默认调用
dlclose/FreeLibrary，尤其当动态库内含全局单例或静态对象时——建议让用户显式调用Library::unload()，并在析构中只做句柄置空 - Windows 下
LoadLibrary在多线程中是线程安全的，但FreeLibrary不是：若另一线程正调用该 DLL 中函数，此时卸载会导致访问违规。必须由业务层保证“无活跃调用时才卸载” - Linux 下
dlopen后若主程序fork()，子进程不会继承 handle，也不能再用该 handle 调dlclose—— 这种场景下封装层最好禁止 fork 后继续使用 Library 对象
跨平台动态库加载器真正的复杂点不在语法，而在不同系统对“模块生命周期”的定义根本不同。你得先决定：是要模拟 Windows 的即时卸载语义，还是 Linux 的引用计数语义，还是干脆禁止卸载、只允许进程退出时由 OS 回收？选错这个，后面所有异常都难定位。
