动态库中单例最危险的是卸载时析构顺序失控，可能导致访问已销毁的std::cout、std::mutex等全局资源而崩溃；应禁用static局部变量单例，改用主程序显式控制init/destroy生命周期。
动态库（.so 或 .dll）中实现单例，最危险的不是多线程初始化，而是卸载时静态对象析构顺序失控——Singleton 实例可能在它所依赖的全局资源（如日志器、内存池、甚至 std::cout）之前被销毁，导致崩溃或未定义行为。
动态库中 static 局部变量的析构时机不可控
C++11 推荐的 static Singleton& getInstance() { static Singleton instance; return instance; } 在主程序中是安全的，但在动态库中不适用：动态库卸载时，其内部所有静态存储期对象的析构顺序由操作系统和链接器决定，不遵循 C++ 标准的“逆序析构”规则。你无法保证 instance 在它用到的 std::mutex、std::string 或其他库级资源之后析构。
- 现象：动态库
dlopen/dlclose后，程序在退出时崩溃，堆栈常卡在~Singleton()中调用std::string::clear()或std::mutex::unlock() - 根本原因：动态库的 .data/.bss 段被 unmapped 前，C++ 运行时尝试调用其静态析构器，但此时标准库对象（如 iostream 全局对象）可能已销毁
- 实操建议：禁用所有在动态库内定义的静态局部变量单例；改用显式生命周期管理，把实例创建/销毁完全交由主程序控制
用 dlopen/dlclose 配合手动 init/destroy 接口
让单例彻底脱离静态存储期，只保留裸指针 + 显式函数接口。这是唯一能跨平台、可预测、可调试的方案。
- 在动态库头文件中导出两个 C 风格函数：
extern "C" void init_singleton();和extern "C" void destroy_singleton(); -
init_singleton()内部用new分配单例（不依赖静态变量），并用std::atomic<bool></bool>标记是否已初始化，避免重复调用 -
destroy_singleton()内部delete实例，并置空指针；必须确保该函数被dlclose前显式调用 - 主程序侧必须严格配对：
dlopen→init_singleton→ 使用 →destroy_singleton→dlclose；漏掉任意一步都可能导致泄漏或二次析构
禁止在单例析构函数中做任何非平凡操作
即使你用了手动管理，析构函数仍可能在不安全上下文中执行——比如系统正在调用 atexit 回调、或主线程已退出、信号处理中。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
~Singleton() { log("shutting down"); db_pool->close_all(); }——log和db_pool此时极可能已失效 - 正确做法：析构函数只释放本类直接持有的原始资源（如
malloc内存、open()的 fd），且必须用if (fd != -1) close(fd);加判空；所有高层逻辑（日志、网络、数据库）应在destroy_singleton()中提前完成 - 额外保护：在
destroy_singleton()开头加std::signal(SIGABRT, SIG_IGN);防止析构途中被信号中断（仅限 Unix）
Windows DLL 的特殊陷阱：DLL_PROCESS_DETACH 不能信任
Windows 下很多人试图在 DllMain 的 DLL_PROCESS_DETACH 中调用 destroy_singleton()，这是高危行为：
- 现象：
DllMain在进程退出阶段被调用时，C 运行时（CRT）可能已关闭，new/delete、std::mutex、甚至printf都会触发访问违规 - 微软明确文档指出：
DLL_PROCESS_DETACH中禁止调用大多数 Win32 API 和 CRT 函数 - 实操建议：Windows 动态库也必须走显式
destroy_singleton()路径，且主程序必须在FreeLibrary前调用它；DllMain里只做标记（如原子变量设为 false），不做实际清理
真正棘手的从来不是“怎么创建唯一实例”，而是“谁来决定它什么时候死、以什么顺序死”。动态库场景下，把单例当成普通堆对象管理，比依赖语言特性更可靠——哪怕多写两行 init/destroy，也比静默崩溃强。
