单例在动态库中无法依赖自动析构，必须显式管理生命周期：Windows用DllMain响应DLL_PROCESS_DETACH，Linux用__attribute__((destructor))配合destroyInstance()，跨平台推荐宿主调用init/shutdown接口。
单例对象在程序退出或动态库卸载时没销毁，不是“忘了写析构函数”，而是生命周期管理方式错了——用 static Singleton* m_instance = new Singleton() 这类堆分配 + 静态指针的写法，根本不会自动析构；而用 static Singleton instance（函数内局部静态）虽能自动析构，但在动态库中又大概率被跳过。必须按场景选对机制。
为什么 static 局部变量在主程序里安全、在 .so/.dll 里不安全
在可执行文件中，static Singleton& getInstance() { static Singleton instance; } 的析构由 __cxa_atexit（Linux）或类似机制注册，程序退出时必然执行。但动态库被 dlclose 或 FreeLibrary 卸载时，运行时不保证调用其内部静态对象的析构函数，尤其当它依赖外部符号（比如日志函数）或跨库资源时，glibc 和 Windows CRT 常直接跳过清理阶段。
常见现象包括：数据库连接未 close、线程未 join、内存池未释放、后续访问悬垂指针崩溃。这不是偶发 bug，而是设计层面的不可靠。
-
static Singleton instance在 .so 中无法依赖自动析构，必须显式接管生命周期 - 若单例析构函数里调用了其他动态库的符号（如
Logger::get().log()），而该库已先卸载，SEGFAULT几乎必然发生 - 不要指望
atexit()补救——它注册的函数在进程退出时才执行，此时动态库代码段可能已 unmapped
Windows DLL 必须用 DllMain 响应 DLL_PROCESS_DETACH
在 DllMain 的 DLL_PROCESS_DETACH 分支中执行销毁，是 Windows 下唯一可控的方式。关键不是“写了销毁逻辑”，而是只在 FreeLibrary 主动卸载时触发，排除进程退出场景。
立即学习“C++免费学习笔记（深入）”；
- 检查
lpReserved参数：if (lpReserved == nullptr)才执行Singleton::destroyInstance()，否则跳过（进程退出时不清理） -
destroyInstance()内部必须用std::atomic<bool></bool>标记已销毁状态，防止多次调用导致重复delete - 销毁前先处理非平凡资源：
thread.join()、mutex.unlock()（或直接放弃锁）、close(fd)，不能依赖析构函数隐式释放 -
getInstance()必须加空指针检查：if (!m_instance) throw std::runtime_error("singleton destroyed");，避免后续误用
Linux SO 必须用 __attribute__((destructor)) + 显式 destroyInstance
__attribute__((destructor)) 函数会在 dlclose 后执行，但它不区分是 dlclose 还是进程退出触发，也不保证执行顺序。所以不能在其中调用其他单例或依赖全局对象，所有清理必须自包含。
- 定义 C 风格函数：
static void __attribute__((destructor)) so_cleanup() { Singleton::destroyInstance(); } -
destroyInstance()必须判空：if (s_instance == nullptr) return;，且使用std::atomic防止多线程并发 delete - 禁止在 destructor 函数中抛异常、调用
std::cout、或任何可能间接依赖已卸载库的接口 - 编译时禁用
-fvisibility=hidden，否则 destructor 函数可能被链接器剥离
跨平台最稳方案：显式 shutdown() 接口 + 宿主控制
把销毁时机完全交给宿主程序，是最可靠、最易测试、最易调试的方式。它绕过了所有运行时析构顺序不确定性，也规避了平台差异。
- 提供
Singleton::init()和Singleton::shutdown()两个 C 风格导出函数（extern "C"），供宿主调用 -
shutdown()内部执行资源关闭、线程终止、指针置空，并返回成功/失败状态，方便宿主判断是否清理干净 - 单例内部不再依赖
static存储期，改用static std::unique_ptr<singleton></singleton>管理，但该 unique_ptr 不声明在全局作用域，而放在 init/shutdown 函数内静态变量中 - 若宿主支持信号（如
SIGINT），应在 signal handler 中调用shutdown()，避免进程被 kill -9 以外方式终止时遗漏清理
真正容易被忽略的是：动态库卸载 ≠ 程序退出，两者的资源可见性、符号存活状态、线程上下文完全不同。用同一套“自动析构”逻辑去覆盖两种场景，注定会漏掉其中一个。
