跨平台动态库加载需封装统一接口类（如DynamicLibrary），用#ifdef _WIN32隔离LoadLibrary/GetProcAddress与dlopen/dlsym，强制extern "C"导出函数，显式处理错误诊断、路径拼接及ABI兼容性。
Windows 和 Linux 下的动态库加载函数名完全不同
跨平台动态库加载最直接的障碍是 API 不统一：LoadLibrary 和 FreeLibrary 是 Windows 的，dlopen、dlsym、dlclose 是 POSIX 的。硬写条件编译容易漏掉错误检查或资源清理路径。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 封装一个统一接口类（如
DynamicLibrary），内部用#ifdef _WIN32/#else分支隔离系统调用，但对外只暴露load()、get_symbol()、unload() - 务必在构造/析构中禁止自动加载/卸载——用户需要显式控制生命周期，否则跨线程或异常栈展开时易出
Access violation或Segmentation fault - Linux 下
dlopen默认使用RTLD_LOCAL，若插件间需共享符号（比如多个 .so 都依赖同个全局变量），得显式传RTLD_GLOBAL
符号获取失败时，Windows 和 Linux 的错误诊断方式差异很大
GetProcAddress 失败只返回 nullptr，不带原因；dlsym 同样只返回 nullptr，但之后必须调用 dlerror() 才能拿到字符串错误信息。直接判空就返回，会丢失关键调试线索。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 封装
get_symbol()时，在 Windows 分支调用GetLastError()并转成可读字符串（如ERROR_PROC_NOT_FOUND→ "procedure not found"） - Linux 分支在
dlsym返回nullptr后立即调用dlerror()，且注意dlerror()返回的是静态缓冲区指针，不能长期持有 - 统一返回
std::pair<void std::string></void>，第二项为空表示成功，非空为错误描述，避免靠bool返回值掩盖细节
C++ 函数符号在动态链接时默认不导出，尤其跨编译器时极易失败
即使 dlopen 成功，get_symbol("my_func") 仍可能返回空——因为 C++ 编译器会对函数名做 name mangling，而 dlsym / GetProcAddress 只认 C 风格未修饰名。Clang、GCC、MSVC 的 mangling 规则互不兼容。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有要被动态加载的函数，必须用
extern "C"声明，例如：extern "C" { void my_plugin_init(); } - Windows 下 DLL 还需额外加
__declspec(dllexport)（头文件中用宏适配），Linux 下确保编译时未加-fvisibility=hidden，或对目标符号显式标注__attribute__((visibility("default"))) - 避免导出模板实例化函数或内联函数——它们没有稳定符号名，运行时必然找不到
路径处理和库名拼接必须按平台规范，否则 load() 直接返回空
Windows 加载 "myplugin.dll"，Linux 加载 "libmyplugin.so"，macOS 是 "libmyplugin.dylib"。硬编码文件名或忽略前缀/后缀，会导致同一段代码在不同平台静默失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 提供静态辅助函数，如
DynamicLibrary::library_name(const std::string& base)，内部根据PLATFORM宏返回"myplugin.dll"、"libmyplugin.so"等 - 路径拼接不要用
+连接字符串，用std::filesystem::path（C++17）或跨平台路径库（如boost::filesystem），避免"./plugins\myplugin.dll"在 Linux 下因反斜杠被当普通字符处理 - Linux 下若从相对路径加载，注意
LD_LIBRARY_PATH不影响dlopen的查找逻辑——它只查绝对路径或RPATH，所以传入前务必用std::filesystem::absolute()转换
std::string）跨 DLL 边界传递，MSVC 下大概率崩溃，GCC 下也可能因分配器不一致导致内存释放错乱。这事没法靠封装类解决，只能靠约定——全部用 C 接口 + 原生类型传参。 
