dlopen加载插件需绕过编译期链接，用extern "C"导出函数、抽象基类+工厂函数约定接口，参数限POD类型，避免跨SO传递STL对象，并严格管理生命周期以防dlclose后崩溃。
怎么用 dlopen 加载插件而不是直接链接
动态加载插件的核心是绕过编译期链接，把模块的符号解析推迟到运行时。C++ 没有原生插件机制，得靠操作系统提供的动态库 API，Linux/macOS 用 dlopen/dlsym，Windows 用 LoadLibrary/GetProcAddress —— 这里只说 POSIX 路线，因为跨平台封装成本高，多数实际项目先保 Linux。
常见错误是试图用 std::shared_ptr 直接管理 void* 返回的插件实例，结果析构时调不到插件自己的析构逻辑；或者把插件里的全局对象当成单例用，却忘了每个 dlopen 加载的副本有独立数据段。
- 插件必须导出 C 风格函数（用
extern "C"），否则 C++ 名字修饰会让dlsym找不到符号 - 主程序不能依赖插件的头文件定义类型，得用抽象基类指针 + 工厂函数约定接口，比如插件导出
create_plugin()和destroy_plugin() -
dlopen(path, RTLD_LAZY | RTLD_LOCAL)更安全：RTLD_LOCAL防止插件符号污染主程序符号表，RTLD_LAZY延迟解析，失败时dlsym才报错而非dlopen就崩
为什么插件里的 std::string 或 STL 容器不能跨 so 边界传递
因为不同编译单元（主程序和插件）可能用不同版本的 libstdc++/libc++，或不同编译选项（如 _GLIBCXX_DEBUG），导致 std::string 内存布局、分配器、异常行为不一致。传过去轻则崩溃，重则静默内存越界。
这不是“能不能”的问题，是 ABI 不兼容的硬限制。哪怕都用 GCC 12 编译，只要链接的 stdlib 版本号差一个 patch，std::vector::push_back 的内部实现就可能变。
立即学习“C++免费学习笔记（深入）”；
- 插件接口函数参数和返回值只能用 POD 类型：
int、const char*、struct（不含虚函数、不含 STL 成员） - 字符串一律用
const char*+ 长度参数，由调用方负责拷贝；需要返回字符串时，插件提供plugin_strdup()并约定调用方用plugin_free()释放 - 如果真要传复杂数据，走序列化：插件输出 JSON 字符串，主程序用统一 JSON 库解析
如何避免 dlopen 失败但没报错的静默陷阱
dlopen 返回 nullptr 表示失败，但很多人只检查指针是否为空，忽略 dlerror() 的具体信息，结果卡在 “找不到符号” 却以为是路径错了。
典型场景：插件依赖另一个 so（比如 libjpeg.so），但没设置 RPATH 或没放对位置，dlopen 就会失败，而错误信息是 “cannot open shared object file”，不是 “symbol not found”。
- 每次
dlopen后立刻调dlerror()清空上一次错误，再检查返回值；不要跳过这步 - 插件编译时加
-Wl,-rpath,'$ORIGIN'，让插件优先从自己所在目录找依赖，避免环境变量干扰 - 调试时用
ldd plugin.so看依赖是否全 resolve，用strace -e trace=openat,openat64 ./main看它到底尝试打开了哪些路径
C++ 类型擦除接口怎么写才不会在插件卸载后崩溃
插件卸载（dlclose）后，所有从该 so 分配的内存、创建的对象、注册的回调都失效。但如果你用 std::unique_ptr 包着插件工厂返回的指针，又没给定制删除器，析构时就会跳转到已卸载 so 的代码段，SIGSEGV。
这个问题比想象中隐蔽：插件可能注册了异步回调，主程序稍后触发，此时插件早已 dlclose，但回调函数指针还存在。
- 插件必须提供显式的销毁函数（如
plugin_shutdown()），且主程序必须在dlclose前调用它，清理所有后台任务、释放资源 - 所有插件返回的对象，其析构逻辑必须封装进插件自己的函数里，主程序通过
dlsym拿到并调用，不能依赖 C++ 自动析构 - 绝对不要保存插件导出的函数指针到全局变量或静态容器里——
dlclose后它们就成野指针了
最麻烦的点其实是生命周期管理：插件不是“加载即用”，它和主程序之间得有一套协商好的启停协议，否则谁先退、谁等谁、资源归谁管，全靠文档约定，一写错就 core dump。
