旧模块卸载前必须等所有活跃调用自然退出，直接dlclose()是热更新崩溃主因；安全做法是停新请求、等老请求跑完，依赖原子计数器轮询归零，函数指针切换需原子同步且调用侧禁止缓存，状态迁移仅传字节流，禁用跨so虚表与RTTI。
旧模块卸载前必须等所有活跃调用自然退出
直接 dlclose() 就走人，是热更新崩溃的头号原因。只要还有线程栈上留着旧 so 里的函数调用帧（哪怕只是一行 std::string 构造），内核就可能回收那段代码段或数据段，下一次访问立刻 Segmentation fault。
真正安全的做法是：先停新请求，再等老请求自己跑完。核心靠一个原子计数器：
- 每次进入旧模块函数前，执行
ref_count.fetch_add(1, std::memory_order_relaxed) - 函数返回前，执行
ref_count.fetch_sub(1, std::memory_order_relaxed) - 切换前轮询
ref_count.load() == 0，不为零就std::this_thread::yield()或短时 sleep
别用互斥锁保护计数器——它本身要高频进出，锁会成瓶颈；也别依赖 pthread_kill 强制中断线程，协程或信号不安全的上下文里极易出错。
函数指针切换必须原子且调用侧不能缓存
用 std::atomic<void></void> 或 std::atomic<:function>></:function> 存函数地址只是起点。更关键的是：赋值动作必须和函数体就绪严格同步，调用方又必须每次都重新读指针。
立即学习“C++免费学习笔记（深入）”；
- 赋值前确保
dlsym()返回非nullptr，否则写入空指针，第一次调用就崩 - 写入前加
std::atomic_thread_fence(std::memory_order_release)，防止编译器/CPU 把新函数体初始化指令重排到指针更新之后 - 所有业务线程必须每次调用都执行
func_ptr.load()，禁止在循环里存成局部变量——否则永远看不到新版本
常见错误是把 dlsym 结果存在全局裸指针里，再用 std::atomic_store 赋值，但忘了检查返回值；或者调用侧优化成只读一次指针、反复调用，结果卡死在旧逻辑里。
状态迁移只能传字节流，主程序绝不碰 STL 对象
两个 so 的 std::string、std::shared_ptr 内存布局可能完全不同——尤其跨 GCC 版本或不同构建选项时。sizeof(std::string) 都可能变，直接传递对象等于埋雷。
- 旧插件提供
serialize_state()，返回void*+size_t（建议用 flatbuffer 或自定义二进制结构） - 新插件提供
restore_state(const void*, size_t)，自行解析并重建内部状态 - 主程序只负责搬运这段内存，不
memcpy、不reinterpret_cast、不调用任何构造/析构
如果状态含文件描述符、线程句柄等资源，需在 cleanup_module() 里显式关闭，不能指望 OS 自动回收——旧 so 卸载后这些 fd 可能已失效，但没关干净会泄漏。
虚表与 RTTI 跨 so 失效，dynamic_cast 必须禁用
主程序定义基类，插件导出子类实例，然后主程序用 dynamic_cast 转型？90% 情况下失败，因为虚表地址、type_info 地址、RTTI 元数据都绑定在各自 so 的地址空间里，跨 so 不互通。
- 插件接口必须用纯虚函数+ extern "C" 工厂函数导出，避免任何运行时类型识别
- 若需多态行为，统一通过基类虚函数调用，不要在主程序里做类型判断
- 禁用所有
dynamic_cast、typeid、异常捕获（catch(...)在跨 so 边界也极不可靠）
最容易被忽略的是：即使你没写 dynamic_cast，某些第三方库（比如部分日志框架或序列化库）内部可能隐式使用了 RTTI，加载新 so 前务必确认它们是否支持跨 so 运行。
