插件加载应使用dlopen+dlsym（Linux）或LoadLibrary+GetProcAddress（Windows）实现运行时动态加载，而非静态链接；需用extern "C"导出纯C接口、POD参数，通过工厂函数管理生命周期，避免C++ ABI不兼容与内存错误。
插件怎么加载：用 dlopen + dlsym 而不是静态链接
动态加载插件本质是运行时打开共享库（.so 或 .dll），不能靠 #include 或静态链接。Linux 下必须用 dlopen 打开，再用 dlsym 获取函数指针；Windows 对应是 LoadLibrary 和 GetProcAddress。别试图把插件类直接 new 出来——没 vtable、没 RTTI、跨模块析构会崩溃。
关键点：
-
dlopen的mode参数建议用RTLD_LAZY | RTLD_LOCAL：延迟绑定避免启动卡顿，RTLD_LOCAL防止符号污染主程序或其他插件 - 插件导出的函数必须是 C 风格（
extern "C"），否则 C++ 名字修饰会让dlsym找不到符号 - 不要在插件里调用
std::cout或抛异常到主程序边界——异常跨dlopen边界未定义行为，输出可能缓冲错乱
热更新怎么安全替换：先卸载再加载，且必须保证无引用残留
热更新不是“覆盖文件后重 load”，而是“旧插件停服 → 卸载 → 新插件加载 → 启动”。难点不在加载，而在确保旧插件所有资源（线程、定时器、回调注册、全局对象）已彻底释放。
常见翻车点：
立即学习“C++免费学习笔记（深入）”；
- 插件内部启了后台线程，但没提供
stop()接口，dlclose后线程还在跑，访问已卸载内存 → 段错误 - 主程序持有插件对象指针（比如
PluginInterface*），但忘记在dlclose前置空或 delete —— 下次dlsym拿到的是新地址，旧指针变野指针 - 插件注册了信号处理函数或 atexit 回调，卸载后这些回调仍存在，触发时跳转到无效地址
实操建议：每个插件暴露三个 C 函数：create_plugin()、destroy_plugin(PluginInterface*)、plugin_shutdown()，主程序按顺序调用，确认返回成功后再 dlclose。
插件接口怎么设计：用纯虚类 + 工厂函数，避免头文件耦合
主程序和插件共用一个抽象接口头文件没问题，但这个头文件里不能有模板、STL 容器、RTTI 依赖——因为插件编译环境可能和主程序不一致（不同 GCC 版本、不同 libcxx）。接口必须是稳定 ABI 的 C++ 子集。
推荐结构：
- 接口类只含 public 纯虚函数，不含数据成员、构造/析构实现、
std::string成员（改用const char*+size_t） - 插件实现类继承该接口，但工厂函数
create_plugin()返回void*或PluginInterface*，由主程序强制转换（靠约定，不靠 RTTI） - 版本控制加在接口里：例如接口类第一个虚函数是
virtual int get_version() = 0;，主程序加载前先调dlsym拿到它，检查是否兼容
为什么 dlclose 不一定真正卸载：glibc 的引用计数机制
dlclose 只是减少引用计数，不是立即释放内存。如果插件 A 依赖插件 B（dlopen("B.so") 在 A 的代码里），而主程序只对 A 调 dlclose，B 依然驻留——这会导致热更新后 B 的旧版本还活着，A 的新版本调用 B 时行为错乱。
更隐蔽的问题：
- 插件用了
libstdc++.so的全局状态（如 locale、new handler），dlclose不会重置它 - glibc 的 malloc arena 是进程级的，插件分配的内存不会因
dlclose自动归还，容易误判内存泄漏 - 调试时用
lsof -p PID | grep so看实际加载的库，比只信dlclose返回值靠谱
真正可控的热更新，得从依赖图拓扑排序开始管理加载/卸载顺序，而不是单点调用 dlclose 就以为完事了。
