Linux下重载动态库前必须dlclose旧句柄，否则新符号不覆盖旧映射；Windows需确保线程退出插件代码再FreeLibrary；跨平台须统一接口类型、严格匹配函数指针，并妥善管理资源与状态迁移。
Linux 下用 dlopen 重载动态库前必须 dlclose
不显式卸载旧句柄就直接 dlopen 同名路径，新符号不会覆盖旧映射——系统认为这是“另一个加载实例”，旧函数指针仍指向原内存页，调用后行为未定义。常见现象是：改了插件代码、重新编译、dlopen 成功，但调用的还是老逻辑。
- 每次重载前必须先
dlclose上次返回的void*句柄，且确认返回值非 0（失败时需查dlerror） -
dlopen路径尽量用绝对路径，相对路径依赖当前工作目录，热加载时容易因进程 cwd 变化导致加载错文件 - 若插件内部用了全局变量或静态局部变量，
dlclose后其生命周期结束；重载后再访问会触发段错误——这类状态必须外提或用共享内存管理
Windows 上 FreeLibrary 失败常因线程还在执行插件代码
在插件 DLL 正在被某个线程执行（比如回调函数中途）时调用 FreeLibrary，系统会延迟卸载，直到所有线程退出该 DLL 的代码段。此时立刻 LoadLibrary 新版本，可能因旧模块未完全释放而加载失败，错误码常为 ERROR_BUSY 或静默失败。
- 必须设计同步机制：插件提供
shutdown()接口，在调用FreeLibrary前确保所有工作线程已退出插件函数栈 - 避免在 DLL 的 DllMain 中做复杂操作（如创建线程、等待事件），否则极易引发死锁或卸载卡住
- 可考虑用引用计数 + 异步卸载：主线程发信号让插件线程自行退出，再轮询
GetModuleHandle是否为空，最后调用FreeLibrary
跨平台热加载时函数指针类型必须严格匹配
插件导出的 C 函数，头文件声明和实际实现只要有一个参数类型不一致（比如 int vs long、const char* vs char*），在不同平台 ABI 下可能表现为调用崩溃、参数错位或静默数据损坏。尤其在 macOS 和 Windows x64 上，寄存器传参规则差异会让问题更隐蔽。
- 插件接口头文件必须由宿主工程统一提供，禁止插件自行定义 typedef 或宏覆盖基础类型
- 推荐用固定宽度类型：
int32_t、uint8_t，避免size_t或long这类平台相关类型 - 函数指针赋值时务必强制类型转换，不要依赖隐式转换：
auto fn = (plugin_init_fn)dlsym(handle, "init");
插件重载期间如何避免资源泄漏和状态不一致
热加载不是原子操作：卸载旧库、加载新库、重新初始化之间存在时间窗口。若插件持有文件句柄、GPU buffer、网络 socket 等资源，且未在 dlclose/FreeLibrary 前主动释放，这些资源会泄漏；更危险的是，新插件初始化时误复用旧状态（比如读取了未清空的缓存结构体）。
立即学习“C++免费学习笔记（深入）”；
- 宿主必须定义清晰的生命周期钩子：
init、shutdown、reload_prepare（用于保存/迁移关键状态） - 禁止插件在全局构造函数中分配资源；所有资源获取必须在
init中显式完成 - 若插件使用 C++ 类，导出函数只能是
extern "C"C 风格函数，类对象生命周期由宿主管理，不能在 DLL 内 new/delete 跨边界对象
热加载真正难的从来不是调用哪个 API，而是怎么让两个版本的代码在内存里和平共处几毫秒——状态迁移、资源移交、线程同步，每一步都得亲手踩过坑才知道边界在哪。
