static local单例能自动析构是因为c++11保证其静态存储期及程序退出时逆序调用析构函数，而new方式因对象在堆上不被自动清理；动态库卸载时static local析构不保证执行，需显式raii管理或避免跨单例依赖。
单例对象在程序退出或动态库卸载时没被析构，不是“忘了写析构函数”，而是它根本不在静态存储期——static T* m_instance = new T() 这种写法，指针是静态的，但 T 对象在堆上，C++ 不会自动 delete 它。
为什么 static local 变量方式能自动析构
函数内定义的 static T instance 是静态存储期对象，C++11 起强制保证：首次调用时构造，程序退出（main 返回后）按构造逆序自动调用其析构函数，由编译器通过 __cxa_atexit 等机制注册清理逻辑。
- 无需
new/delete，不依赖atexit，无悬挂指针风险 - 线程安全初始化（C++11 标准要求），多个线程首次并发调用
getInstance()不会重复构造 - 析构时机独立于其他编译单元的静态对象，避开“跨文件析构顺序未定义”这个经典崩溃源
- 若单例构造失败（抛异常），该实例不会被标记为已构造，后续调用会重试，且不会触发析构
动态库卸载时单例仍存活？那是 static local 没用对
在动态库（.so / .dll）中使用单例，若库被 dlclose 或等价机制卸载，而单例又是函数内 static T instance，其析构**不一定执行**——因为 C++ 标准只保证程序退出时析构，不保证动态库卸载时触发。
- POSIX 下
dlclose不保证调用静态局部变量析构函数（GCC 实现通常不调） - Windows 的
FreeLibrary同样不承诺执行 DLL 内静态局部变量的析构 - 真正可控的做法：把单例生命周期绑定到显式管理的 RAII 类上，例如
SingletonManager::init()和SingletonManager::shutdown()，并在库的入口/出口函数（如DllMain或__attribute__((constructor/destructor))）中调用 - 若必须用 static local，至少确保析构函数不访问任何可能已被卸载的符号（比如不调用其他库的函数、不操作全局日志器）
std::unique_ptr 或内部 GC 类反而更危险
用 static std::unique_ptr<t></t> 或内部 class GC 手动 delete m_instance，看似“自动”，实则引入新问题：
-
std::unique_ptr本身是静态变量，它的析构仍受跨编译单元析构顺序影响；若它比所依赖的Logger或Config先析构，~T()中访问这些对象就会崩溃 - 内部
GC类必须在类外显式定义（如Singleton::GC Singleton::gc;），否则该静态成员根本不会被构造，析构函数永远不会运行 - GC 析构函数里必须判空：
if (m_Instance) { delete m_Instance; m_Instance = nullptr; }，否则多次加载/卸载库时可能重复delete同一地址 - 所有依赖项（如文件句柄、线程池）应在析构函数中仅做轻量关闭，避免调用其他单例或复杂逻辑
真正难的不是“怎么写析构”，而是“析构时还能安全访问什么”。哪怕用了最标准的 Meyer 单例，只要析构函数里调了另一个单例的接口，而那个单例在链接时恰好排在前面被销毁了，就注定崩溃——这种问题只在特定构建配置下暴露，调试成本极高。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
