如何在c++中实现一个跨平台的动态库加载器？ (dlopen/LoadLibrary封装)_技术教程

不能直接用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 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）

符号获取时最容易崩的几个坑

最常见崩溃不是找不到符号，而是类型擦除后强制转函数指针时调用约定/参数尺寸不匹配。例如：

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 对象