动态库中单例析构顺序不可控，易因访问已销毁依赖而崩溃；应改用显式init/shutdown双阶段管理，禁用自动析构，并在主程序中主动调用destroy。
动态库（.so / .dll）卸载时，单例的析构顺序不可控，极易触发静态对象析构时访问已销毁的依赖资源 —— 这不是“要不要销毁”的问题，而是“销毁时机是否在所有依赖之后”；C++ 标准不保证跨编译单元的静态对象析构顺序，而动态库的卸载过程会强制析构其内部所有静态对象，若此时单例仍持有对主程序或其他已卸载模块中对象的引用，就会 crash。
动态库中静态局部变量单例的析构风险
C++11 的 static Singleton& instance() 写法虽线程安全，但在动态库中极其危险：函数内静态局部变量的析构由动态链接器在 dlclose() 时触发，但析构时机完全取决于加载器实现和符号可见性，且无法干预。更糟的是，它可能比主程序中依赖它的其他静态对象更晚析构，导致访问野指针。
- 现象：
dlclose()后出现段错误，gdb 显示崩溃在单例析构函数中调用某std::string成员的析构 - 原因：该
std::string所在的 stdc++ 库（或其全局状态）可能已被先卸载/释放 - 关键点：
static局部变量的生命周期绑定到所在模块的加载/卸载周期，不是程序生命周期
改用显式初始化 + 手动注销的双阶段管理
放弃“自动析构”幻想，把单例生命周期拆成两段：模块加载后显式初始化（init()），模块卸载前显式注销（shutdown()）。这是唯一可控的方式。
- 单例类不暴露
getInstance()，只提供create()和destroy()，且create()必须被调用一次才允许后续访问 - 所有对外接口（如
doSomething()）开头加运行时检查：if (!instance) throw std::runtime_error("Singleton not initialized"); -
destroy()中置空指针、释放资源，并确保不访问任何可能已失效的跨模块对象（例如避免调用主程序注册的回调函数） - 在动态库的
__attribute__((destructor))（Linux）或DLL_PROCESS_DETACH（Windows）中仅调用shutdown()，不执行任何实际逻辑 —— 把控制权交给上层
避免跨模块静态依赖的三个硬约束
单例析构失败，90% 是因为它间接依赖了其他模块的静态对象。必须从设计上切断这些链路。
立即学习“C++免费学习笔记（深入）”；
- 禁止在单例析构函数中调用任何非本模块定义的函数（包括
std::cout、malloc、日志宏等），它们底层可能依赖已卸载的 libc 或 libstdc++ 符号 - 所有资源（如文件句柄、socket、内存池）必须在
destroy()阶段就释放完毕；析构函数里只做空操作或极轻量的指针置空 - 不要用
std::shared_ptr管理单例本身 —— 它的控制块析构会触发delete，而delete可能调用已被卸载的 operator delete 替代实现
Windows DLL 下特别注意 DllMain 的限制
在 DLL_PROCESS_DETACH 中调用单例 destroy() 是可行的，但有严格前提：
- 必须检查
lpReserved参数：仅当lpReserved == nullptr（即正常进程退出）才执行清理；若为非空（如FreeLibrary失败回滚），跳过销毁 - 不能调用任何可能触发 DLL 加载的 API（如
LoadLibrary、GetProcAddress、CreateThread） - 不能使用 C 运行时锁（如
printf）、C++ 异常、STL 容器 —— 它们在 DLL 卸载后期可能已不可用
最稳妥的做法是：把 destroy() 声明为 extern "C" 导出函数，由主程序在 FreeLibrary 前主动调用，彻底绕开 DllMain 的雷区。
