核心难点在于三平台API在符号可见性、错误处理、路径解析上本质不同：Linux默认不搜LD_LIBRARY_PATH外路径，macOS拒绝非@rpath dylib，Windows自动补.dll并遍历PATH；必须用绝对路径、显式后缀、extern "C"导出、依赖链检查。
Linux/macOS/Windows 上 dlopen/dlsym 与 LoadLibrary/GetProcAddress 的行为差异
跨平台动态库加载器的核心难点不是“怎么写”，而是三套 API 在符号可见性、错误处理、路径解析上根本不是一回事。Linux 的 dlopen 默认不搜索 LD_LIBRARY_PATH 以外的路径，macOS 的 dlopen 默认拒绝加载非 @rpath 相对路径的 dylib，Windows 的 LoadLibrary 则会自动拼接 .dll 后缀并遍历 PATH —— 这些默认行为一旦混用，就会在某个平台上静默失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 统一用绝对路径调用
dlopen或LoadLibrary，避免依赖环境变量或当前工作目录；可先用std::filesystem::absolute归一化路径 - macOS 必须在编译 dylib 时加
-install_name @rpath/libxxx.dylib，否则dlopen("libxxx.dylib")一定失败 - Windows 下若传入不含扩展名的路径（如
"myplugin"），LoadLibrary会自动尝试.dll，但 Linux/macOS 的dlopen不会补后缀，必须显式写"libmyplugin.so"或"libmyplugin.dylib" - 所有平台都应检查返回值：Linux/macOS 看是否为
nullptr，Windows 看是否为nullptr且调用GetLastError()获取具体错误码
如何封装统一的符号获取接口，避开 C++ 名字修饰问题
直接用 dlsym 或 GetProcAddress 拿 C++ 成员函数地址会失败，因为编译器做了名字修饰（name mangling）。这不是跨平台问题，而是 C++ 语言层限制 —— 跨平台加载器必须只加载 extern "C" 导出的函数。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 被加载的库必须用
extern "C"声明导出函数，例如：extern "C" { void* create_processor(); void destroy_processor(void*); } - 封装层不要试图“自动 demangle”，C++ 标准不保证 mangling 规则跨编译器一致，GCC/Clang/MSVC 各自不同
- 若需导出类实例，约定一个工厂函数（如
create_instance）返回void*，由调用方强制转换为已知结构体指针 —— 该结构体定义必须在主程序和插件间完全一致（推荐用头文件共享，而非字符串解析） - Windows 上若用 MinGW 编译插件，注意其
__declspec(dllexport)行为与 MSVC 不完全兼容，建议统一用 GCC/Clang 工具链
Windows 下 LoadLibrary 失败但 GetLastError() 返回 0 的真实原因
这是最常被忽略的坑：LoadLibrary 返回 nullptr 但 GetLastError() 是 0，往往不是库本身问题，而是它依赖的某个 DLL 找不到（比如 MSVCRT 版本不匹配、OpenSSL 缺失、甚至系统组件如 VCRUNTIME140.dll 未安装）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要只查目标 DLL 是否存在，用
dumpbin /dependents myplugin.dll（Windows）或otool -L（macOS）、ldd（Linux）看完整依赖树 - Windows 下启用 “应用事件查看器 → Windows 日志 → 应用程序”，筛选“SideBySide”错误，能定位 manifest 或 CRT 版本冲突
- 开发期可在代码中调用
SetErrorMode(SEM_FAILCRITICALERRORS)防止弹窗干扰调试，但发布时务必关掉 - 避免在 DLL 中静态链接 C 运行时（/MT），改用动态链接（/MD），否则极易因 CRT 版本不一致导致
LoadLibrary静默失败
跨平台路径拼接与插件发现逻辑该怎么写才可靠
不能靠 "./plugins/" + name + ".so" 这种硬拼，因为 macOS 默认禁用当前目录搜索，Windows 对路径分隔符敏感，而 Linux 可能挂载在任意位置。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::filesystem::path拼接，它自动处理分隔符：auto lib_path = std::filesystem::current_path() / "plugins" / ("lib" + name + ".so"); - 插件发现不要只扫一个目录：主程序路径、用户配置目录（如
~/.config/myapp/plugins）、系统级路径（如/usr/lib/myapp）都应纳入，按优先级顺序尝试dlopen/LoadLibrary - Linux 下若用
RTLD_GLOBAL加载多个插件，注意符号冲突风险 —— 同名全局变量或函数会导致后加载的覆盖先加载的，除非明确需要此行为，否则一律用RTLD_LOCAL - macOS 的
dyld有严格的签名验证，开发期可临时用codesign --force --deep --sign - myplugin.dylib绕过，但上线必须用有效证书签名，否则dlopen直接拒绝
真正的难点不在 API 封装，而在每个平台的隐式约束：macOS 的签名和 rpath、Windows 的 DLL 依赖树、Linux 的符号绑定时机。这些约束不会报错，只会让 dlopen 返回空指针或程序在某台机器上随机崩溃。动手前先用 ldd/otool/dumpbin 看清依赖链，比写一百行封装代码都管用。
