动态库卸载时单例对象几乎从不安全销毁，唯一可靠方案是宿主显式调用跨平台shutdown接口：导出extern "c"函数，仅delete实例并置空指针，且调用后立即dlclose/freelibrary。
动态库卸载时，单例对象几乎从不安全销毁——这不是配置问题，而是 C++ 标准与操作系统加载机制共同决定的事实。你不能依赖 static Singleton instance; 的析构函数在 dlclose() 或 FreeLibrary() 后执行，它大概率被跳过，留下悬垂指针、未关闭句柄、已释放内存访问等崩溃源头。
Windows 下 DllMain 的 DLL_PROCESS_DETACH 不等于安全销毁
很多人以为只要在 DllMain 的 DLL_PROCESS_DETACH 分支里调用 Singleton::destroyInstance() 就万事大吉，但实际踩坑点极多：
-
lpReserved必须为nullptr才表示是FreeLibrary主动卸载；若为非空，说明是进程退出，此时 CRT 堆可能已失效，delete会直接段错误 -
destroyInstance()内部不能调用任何外部 DLL 导出函数（包括日志、配置、网络），因为那些模块可能已被先卸载 - 不能在
destroyInstance()中调用getInstance()—— 此时静态局部变量的初始化状态不可靠，可能返回已析构或未构造的对象 - 所有
std::thread必须先joinable()判断再join()，否则join()会抛异常或死锁
Linux SO 的 __attribute__((destructor)) 有严重执行约束
__attribute__((destructor)) 函数看似自动，但它根本不是“卸载钩子”，而只是“共享库卸载后、进程退出前”的一个回调，且顺序完全不可控：
- 仅对
dlopen()加载的 SO 生效；直接链接的.so不触发 - 函数执行时，
std::cout、std::mutex、std::string等 STL 对象可能已析构，调用它们会崩溃 - 不能依赖任何其他全局对象（比如另一个单例、静态配置表），因为其析构顺序未知
- 必须配合原子标记：
static std::atomic<bool> s_destroyed{false}; if (s_destroyed.exchange(true)) return;</bool>，否则多线程卸载时可能重复 delete
显式 shutdown() 接口才是跨平台唯一可靠方案
把销毁时机交还给宿主程序，是最可控、最可测试、最容易调试的方式。关键不是“能不能写”，而是“怎么导出、怎么调用、怎么防御”：
- 导出函数必须用
extern "C"+__declspec(dllexport)（Windows）或__attribute__((visibility("default")))（Linux），避免 name mangling - 函数签名建议为：
extern "C" void shutdown_singleton();，内部只做两件事：判空delete实例指针、置m_instance = nullptr - 宿主调用顺序必须严格为：
shutdown_singleton();→dlclose(handle);（Linux）或FreeLibrary(hDll);（Windows）；中间不能有异常或提前 return - 禁止在
shutdown_singleton()中调用任何跨模块函数（含日志），可用裸write(2)或OutputDebugStringA做极简调试输出
thread_local + 单例组合极易引发卸载死锁
如果单例内部用了 thread_local 缓存资源（如每个线程一个数据库连接），卸载时这些 thread_local 变量的析构函数可能晚于单例本身执行，导致访问已销毁的单例成员：
- 不要在
thread_local析构函数中调用Singleton::getInstance()或任何单例方法 - 改用函数内静态局部变量实现惰性初始化：
static auto& conn = []{ return std::make_unique<db_conn>(); }();</db_conn> - 若必须感知单例状态，用
std::atomic<bool> s_shutdown_flag{false};</bool>，在shutdown_singleton()中置 true，thread_local析构前先检查 - 所有线程必须在调用
shutdown_singleton()前完成对单例的访问，否则仍是未定义行为
最常被忽略的一点：销毁函数本身不能成为新的依赖源。一旦你把 shutdown_singleton() 写成“先关日志、再关数据库、最后删缓存”，就等于把日志模块的生命周期强行绑定到单例上——而日志模块很可能比单例更早卸载。真正的安全边界，是销毁函数只操作本库内分配、本库内定义的资源，其余一概不管。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
