最轻量兼容的插件加载方式是直接用系统API：Windows用LoadLibrary/GetProcAddress，Linux用dlopen/dlsym；关键在于正确导出符号、立即检查错误、避免C++ ABI问题、统一用C接口传递数据。
Windows 下用 LoadLibrary 和 GetProcAddress 加载 DLL
直接调用系统 API 是最轻量、兼容性最好的方式，不需要第三方库或构建工具介入。关键不是“能不能”，而是“怎么安全地做”。
常见错误现象：LoadLibrary 返回 NULL 但没查 GetLastError()；GetProcAddress 拿到函数指针后直接调用，结果崩溃——因为符号被 C++ name mangling 扰乱了。
- 导出函数必须用
extern "C"声明，否则GetProcAddress找不到符号（例如：extern "C" __declspec(dllexport) int plugin_init();） - 加载失败时，立刻调用
GetLastError()，常见返回值：ERROR_MOD_NOT_FOUND（路径错）、ERROR_PROC_NOT_FOUND（函数名不匹配）、ERROR_DLL_NOT_FOUND（依赖的 DLL 缺失） - 不要把
HMODULE存全局变量后长期持有——DLL 卸载后指针变悬空；每次调用前应检查是否仍有效（可配合引用计数或 RAII 封装）
Linux 下用 dlopen/dlsym 加载 SO，注意 ABI 和符号可见性
和 Windows 类似，但默认符号是隐藏的，不加配置就导不出函数。
使用场景：你写了个 libplugin.so，主程序用 dlopen("./libplugin.so", RTLD_LAZY) 打开，却在 dlsym 时返回 NULL。
立即学习“C++免费学习笔记（深入）”；
- 编译 SO 时必须加
-fPIC，链接时加-shared；导出函数需显式标记__attribute__((visibility("default")))，或整体用-fvisibility=default（不推荐，污染面大） -
dlopen失败时，用dlerror()取错误字符串，不是 errno；常见问题：file not found（路径非绝对且没进LD_LIBRARY_PATH）、undefined symbol（依赖的符号在主程序里未导出或未链接） - 避免在 SO 里静态初始化全局对象——若主程序和插件都用了 STL，可能触发双重初始化或内存管理冲突；优先用纯 C 接口 + 显式 init/destroy 函数
跨平台封装时，别碰 std::function 或虚函数表传参
想统一管理插件接口？直接继承抽象基类或塞 std::function 进结构体，看似干净，实则埋雷。
性能 / 兼容性影响：不同编译器、不同 STL 版本、甚至同一编译器不同构建选项（如 _GLIBCXX_DEBUG），会让 std::function 对象二进制布局不一致；虚函数表地址在跨模块时无法保证稳定。
- 只传 C 风格函数指针：
typedef int (*plugin_entry_t)(int, const char**);，所有数据通过参数或回调函数传递 - 插件生命周期由主程序控制：提供
plugin_load/plugin_unload两个 C 函数，中间状态全靠传入的上下文void*维护 - 如果必须传对象，用 opaque handle（比如
struct plugin_ctx*）+ 一整套 C 函数操作它，而不是暴露 class 定义
调试时 GetLastError 或 dlerror 返回空？说明调用链断了
不是 API 失败，而是你没在失败后「立刻」查错误——中间任何一次系统调用、日志打印、甚至 printf 都可能覆盖掉它。
容易踩的坑：在 LoadLibrary 后隔了几行代码才调 GetLastError，结果返回 0；或者多线程环境下，另一个线程触发了错误，把你这个线程的错误码冲掉了。
- Windows：查错必须紧跟在疑似失败的 API 后，且中间不能调任何可能设错的 Win32 函数（包括
OutputDebugString） - Linux：同理，
dlerror()是线程局部的，但必须在dlopen/dlsym返回NULL后立即调，不能先 printf 再查 - 更稳的做法：封装一层，比如
safe_dlopen(const char* path)，内部调dlopen→ 判空 → 立即存dlerror()结果到局部变量 → 返回带错误信息的结构体
插件路径、符号名、调用约定、ABI 兼容性——这四样只要有一样对不上，就静默失败。调试时别猜，先锁死这四个点，再动代码。
