插件接口必须用纯虚类 + dlopen 手动符号解析
直接继承抽象基类再 dlopen 加载 SO，运行时会崩溃——C++ ABI 不保证跨模块的 vtable 布局一致，尤其不同编译器或 STL 版本下。真正能落地的方式是：插件导出一个工厂函数（如 create_plugin()），宿主用 dlsym 拿到函数指针后调用，返回一个通过纯虚接口指针传递的对象。
常见错误现象：segmentation fault 在首次调用插件虚函数时发生；或者 dynamic_cast 返回 nullptr 即使类型匹配。
- 插件 SO 必须用
-fPIC -shared编译，且不能链接宿主的 STL 符号（禁用-static-libstdc++） - 宿主与插件需统一使用相同 C++ 标准库（如都用
libstdc++，而非一个用libc++） - 工厂函数签名必须是 C 链接（
extern "C"），否则dlsym找不到符号
dlclose 不能安全卸载正在被调用的插件
Linux 的 dlclose 是引用计数机制，但不会阻塞或等待当前正在执行的函数返回。如果插件回调还在宿主线程栈中运行，此时 dlclose 后立刻 dlclose 或再次 dlopen 同名库，极大概率触发 undefined symbol 或段错误。
使用场景：热更新时先停业务流、等所有插件调用退出、再卸载；不是“调个函数就完事”。
- 必须在插件无任何活跃调用栈时才调用
dlclose（例如：插件已进入 idle 状态，且宿主已取消所有定时器/事件监听） - 推荐用引用计数 + 弱回调管理插件生命周期，而不是依赖
dlclose的“立即释放”假象 -
RTLD_NODELETE可临时规避卸载问题，但会累积内存——仅用于调试，不可上线
插件间通信只能走宿主中转，禁止直接 dlsym 跨插件取函数
两个插件 A 和 B 都由宿主加载，A 想调 B 的某个函数？别用 dlsym(RTLD_DEFAULT, "func_in_b") ——符号可见性取决于加载顺序和 RTLD_GLOBAL 标志，行为不可控，CI 环境下极易偶发失败。
性能影响：看似绕路（A → 宿主 → B），实则更稳定；且宿主可统一做超时、熔断、日志埋点。
- 宿主暴露统一的
plugin_service_registry接口，插件启动时注册自身服务名（如"audio_encoder_v2"） - 插件通过宿主的
get_service("audio_encoder_v2")获取弱引用接口指针，不持有 SO 句柄 - 服务名必须带版本号（如
"logger_v1"），避免插件升级后 ABI 不兼容导致静默错乱
热插拔时配置与状态必须显式迁移，不能靠全局变量或静态成员
插件 SO 卸载后，其内部所有静态变量、全局对象析构顺序不确定，若宿主还存着指向它们的裸指针，下次调用就是野指针。很多团队踩坑在“配置 reload”上：以为重读 config 文件就能恢复状态，其实插件内部缓存的线程池、连接池、LRU 表都没重建。
容易被忽略的地方：插件的初始化函数（init()）和销毁函数（shutdown()）必须成对设计，且宿主要严格按序调用。
-
shutdown()必须同步完成所有资源释放（关闭 socket、join 线程、清空队列），不能只发信号了事 - 状态迁移靠宿主传入
const void* old_state参数给新插件的init()，插件自行反序列化（建议用 flatbuffer 或 msgpack） - 禁止插件内部 new 全局单例；所有“全局”状态必须由宿主分配并传入（如
log_sink、time_provider）
热插拔不是替换一个 SO 文件那么简单，它把模块边界从编译期推到了运行期——每个接口定义、每次内存移交、每处符号绑定，都得经得起卸载重载的反复锤炼。最麻烦的永远不是加载，而是确认“旧插件真死了，新插件真活了”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
