函数内静态变量实现单例是唯一能确保程序退出时自动、安全、线程安全析构的方式，因其析构由c++11标准强制保证：按构造逆序在main返回后由__cxa_atexit注册执行，不参与跨编译单元析构顺序，且完全规避依赖崩溃与漏析构风险。
用函数内静态变量实现单例，是唯一能确保程序退出时自动、安全、线程安全析构的方式。其他所有基于 static T*、atexit 或内部垃圾回收类的方案，都存在漏析构、重复析构、依赖崩溃或跨编译单元顺序失控的风险。
为什么 static local 变量能自动析构
因为 C++11 标准强制规定：函数作用域内的静态对象（非指针），其析构函数会在 main() 返回后、全局对象析构阶段按构造逆序调用，并由运行时通过 __cxa_atexit（GCC/Clang）或等效机制注册清理逻辑。这不是“大概率发生”，而是编译器必须保证的行为。
- 该变量必须是「有析构函数的非 POD 类型」，且定义在函数内部（不能是全局
static Singleton instance;） - 构造发生在首次调用
getInstance()时，线程安全（C++11 起） - 析构不参与全局静态析构序列，因此完全规避「跨 .cpp 文件析构顺序未定义」问题
- 无需
new、delete、atexit或额外辅助类 —— 编译器全托管
static T* + new 的典型销毁失败场景
写成 static T* p = new T() 是最常踩的坑。它把生命周期管理从编译器手里抢过来，却没能力妥善交还。
- 程序退出时，
p这个指针变量会被销毁，但它指向的堆内存不会被自动delete - 若靠
atexit注册删除逻辑，可能在依赖对象（如std::ofstream、std::mutex）已析构后才执行，触发未定义行为 - 若用内部类（如
CGarbo）做回收，必须在类外显式定义Singleton::CGarbo Singleton::garbo;，否则该类根本不会构造，析构函数永远不会调用 - 即使补上了定义，若单例构造失败（比如配置加载失败导致提前返回），
m_instance仍为nullptr，而CGarbo::~CGarbo()中未判空就delete，直接崩
DLL/so 模块卸载时单例必须手动销毁
静态局部变量的析构只在主可执行程序正常退出时受保障；DLL（Windows）或共享库（Linux）被 FreeLibrary/dlclose 卸载时，该机制失效 —— 析构函数极大概率被跳过，资源泄漏或崩溃几乎必然发生。
- Windows 下必须在
DllMain的DLL_PROCESS_DETACH分支中调用Singleton::destroyInstance() - Linux 下可用
__attribute__((destructor))，但执行顺序无保证；更可靠的是提供显式shutdown()接口，由宿主控制调用时机 -
destroyInstance()必须幂等：std::atomic<bool></bool>标记是否已销毁，销毁前加锁（如果单例支持并发访问），销毁后将指针置为nullptr - 不能在析构函数中调用其他单例（如日志、配置），否则模块卸载顺序错乱时会访问野指针
析构函数里该做什么、不该做什么
即使用了 Meyer 单例，也不能默认析构一定安全执行。真正关键的资源释放，得靠设计兜底，而不是赌析构时机。
- 析构函数中只做轻量操作：关闭文件描述符、
munmap内存映射、pthread_cancel线程、发送 shutdown 通知 —— 不依赖其他单例，不抛异常 - 避免在析构中调用
std::cout、std::cerr或任何可能依赖已销毁全局流对象的操作 - 若单例持有数据库连接、网络 socket 或共享内存段，建议业务层主动调用
shutdown()方法，而非完全等待析构 -
std::quick_exit()或_Exit()会跳过所有析构函数；主线程调用exit()而其他线程仍在运行时，静态局部变量析构也只在主线程上下文中发生，可能引发竞态
最易被忽略的一点：析构安全 ≠ 构造安全。如果单例构造函数里访问了另一个用全局静态变量实现的配置类，而那个配置类在链接时被排在后面初始化，构造就会失败或 UB —— 所以所有依赖，都得是同样用函数内静态变量实现的 Meyer 单例。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
