单例模式破坏依赖显式性、阻碍测试隔离、引发生命周期耦合、导致头文件污染与编译依赖爆炸，其便利性以牺牲可维护性为代价。
单例模式直接暴露全局状态，破坏依赖显式性
调用方不需要声明自己依赖什么，只要在任意位置写 Singleton::getInstance() 就能拿到对象。这看起来方便，实则把依赖关系藏进了实现细节里——编译器不报错、链接器不警告、IDE 很难自动追踪。模块 A 的头文件里没出现 Singleton，但它的某个函数内部悄悄调用了它，模块 B 想复用 A 就不得不连带引入 Singleton 及其全部依赖链。
测试时无法替换依赖，导致测试僵化
单元测试需要隔离被测模块，通常靠注入模拟对象（mock）来控制边界行为。但单例的获取方式是静态的、硬编码的，getInstance() 返回的永远是真实实例。你没法在测试中让它返回一个伪造的日志器或空配置器。结果就是：要么测试必须启动完整环境（比如连上真实数据库），要么干脆跳过对依赖路径的覆盖。
生命周期耦合不可控，销毁顺序成雷区
多个单例之间若存在隐式依赖（比如 Logger 析构时要调用 Config 的方法），而它们又都是静态存储期对象，C++ 仅保证同一翻译单元内按定义顺序构造、逆序析构，跨单元的顺序完全未定义。常见现象是：程序退出时 Config 先析构了，Logger 再析构就访问已释放内存，触发 use-after-free —— 这类 bug 往往只在特定构建顺序或优化级别下才暴露。
头文件污染与编译依赖爆炸
只要一个源文件包含了单例头文件，它就间接依赖该单例所包含的所有头（比如 Singleton.h 引入了 database_connection.h 和 json_parser.h）。修改底层依赖头文件会导致大量无关模块重新编译。更麻烦的是，如果单例类本身模板化或带宏配置，还可能引发 ODR（One Definition Rule）冲突，尤其在跨 DLL/so 场景下，getInstance() 在不同模块里可能返回不同地址的“同一个单例”。
立即学习“C++免费学习笔记（深入）”；
单例不是不能用，但它的“方便”是以牺牲可维护性为代价的；真正难处理的从来不是怎么写一个线程安全的getInstance()，而是当项目长到二十万行时，没人能说清谁在什么时候、以什么顺序、通过多少层间接调用动了那个全局实例。 
