根本原因是跨编译单元静态对象析构顺序未定义：GlobalObject析构时调用Logger::getInstance()，而Logger实例可能已被销毁，导致访问已析构对象成员引发段错误。
直接结论：这不是单例没写析构函数的问题，而是跨编译单元静态对象析构顺序未定义导致的——GlobalObject 析构时调用 Logger::getInstance()，而 Logger 实例可能已被销毁。
为什么全局变量析构会访问已销毁单例
现象是崩溃点在 ~GlobalObject() 里调用 Logger::getInstance().log() 时触发段错误。根本原因有两点：
- C++ 标准只保证同一
.cpp文件内静态对象按构造逆序析构，跨文件顺序完全未定义 -
Logger是 Meyer 单例（static Logger instance;），它的析构发生在程序退出阶段，但无法控制它和GlobalObject谁先谁后 - 若链接器恰好让
Logger先析构，GlobalObject::~GlobalObject()再次访问它，就等于访问已析构对象的成员（如内部std::ofstream）→ 未定义行为
用 Meyer 单例 + 显式 shutdown 替代隐式析构
只靠 static Logger instance; 不够安全，必须切断“析构中再访问单例”的链路。推荐组合方案：
- 保留
static Logger& getInstance() { static Logger instance; return instance; }做线程安全初始化 - 增加
static void shutdown()，手动释放资源（如m_stream.close()、m_mutex.unlock()），并置内部状态为无效 - 所有全局对象的析构函数中，改用
if (Logger::isInitialized()) Logger::getInstance().log(...)，避免无条件访问 - 在
main()返回前显式调用Logger::shutdown()，确保它比所有依赖它的全局对象更晚清理
禁止在析构函数中调用任何单例
这是最硬性的约束。哪怕你用了 Meyer 单例，也不能假设它在其他静态对象析构时还“活着”。常见错误包括：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
~GlobalObject()直接调用ConfigManager::getInstance().save() -
~DatabasePool()调用Logger::getInstance().error() - 自定义
atexit()回调里访问单例
正确做法是把日志、配置、连接池等资源释放逻辑全部提前到 main() 末尾或 atexit() 注册的函数中执行，且确保顺序可控；析构函数里只操作本类直接持有的原始资源（如裸指针、文件描述符），不跨依赖。
动态库场景必须彻底禁用 Meyer 单例
如果你的单例定义在 .so 或 .dll 中，static Logger instance; 是高危操作——动态库卸载时析构顺序由操作系统决定，std::string、std::mutex 等标准库全局对象很可能已失效。此时必须：
- 移除所有
static局部变量单例，改用裸指针 +std::atomic<bool></bool>标记 - 导出
extern "C" void init_logger();和extern "C" void destroy_logger(); - 主程序在
dlopen()后立即调用init_logger()，在dlclose()前必须调用destroy_logger() -
destroy_logger()中只释放本模块分配的资源（close(fd)、munmap()），不调用任何外部函数（包括std::cout）
真正棘手的不是“怎么写单例”，而是“谁来决定它什么时候死”——一旦交由运行时自动管理，你就失去了对析构时机的控制权。
