单例自动释放不能靠析构函数直接搞定，因全局对象析构顺序未定义，若单例依赖的其他全局资源先销毁，析构时访问已销毁依赖将导致未定义行为；std::atexit注册清理函数可确保在main返回后、全局析构前执行，此时所有静态对象仍有效。
为什么单例的自动释放不能靠析构函数直接搞定
因为全局对象的析构顺序是未定义的，如果单例依赖其他全局资源（比如日志器、配置管理器），而这些资源先于单例被销毁，Singleton::instance() 返回的对象在析构时访问已销毁的依赖，就会触发未定义行为。单纯在静态局部变量的析构函数里做清理，不解决依赖时序问题。
用 std::atexit 注册释放函数是最小侵入方案
std::atexit 保证注册的函数在 main 返回后、全局对象析构前执行，此时所有静态对象仍有效，适合做单例清理。但注意：它只接受无参 void() 函数指针，不能直接传成员函数或带捕获的 lambda。
- 在单例类内部定义一个静态释放函数：
static void cleanup() { delete instance_; instance_ = nullptr; } - 在首次构造实例后立即调用
std::atexit(&Singleton::cleanup)（仅一次，需加static bool registered = false;防重复） - 确保
cleanup是静态且无状态的——不能访问this或非静态成员
用 std::shared_ptr + 自定义删除器避免手动 delete
把单例实例包装成 std::shared_ptr 并绑定自定义删除器，可延迟释放时机并解耦内存管理逻辑。但要注意：该指针本身必须是静态存储期，否则它的析构又会陷入同样的时序问题。
- 声明为
static std::shared_ptr<singleton> instance_;</singleton> - 初始化时用
std::shared_ptr<singleton>(new Singleton(), [](Singleton* p) { delete p; })</singleton> - 更安全的做法是把删除器设为空（即不释放），改由
std::atexit触发显式reset()，这样控制权更明确
Garbo 类模板实现通用自动注册机制
所谓 “Garbo” 是社区对自动释放辅助类的戏称，本质是一个带静态注册逻辑的 RAII 包装器。它不接管单例创建，只负责在进程退出前调用用户提供的清理回调。
立即学习“C++免费学习笔记（深入）”；
- 定义
template<typename t> struct Garbo { static void register_cleanup(void(*f)()) { std::atexit(f); } };</typename> - 在单例的
instance()中调用Garbo<singleton>::register_cleanup(&Singleton::cleanup)</singleton> - 关键点：注册必须发生在单例首次构造之后，且只能发生一次；
cleanup必须能安全处理instance_ == nullptr的情况（例如多线程竞争下可能尚未完成构造）
真正麻烦的从来不是“怎么删”，而是“删的时候还能不能安全访问别的全局对象”。哪怕用了 std::atexit，如果清理函数里调用了已被析构的日志模块，照样崩。务必把单例的清理逻辑限制在纯内存释放或系统级资源关闭（如 close(fd)），避开对其他 C++ 全局对象的依赖。
