C++11起推荐用静态局部变量实现线程安全单例，即static Singleton& getInstance(){static Singleton instance; return instance;}，其初始化由标准保证线程安全且仅一次。
单例的线程安全初始化必须用 std::call_once + std::once_flag
多线程环境下，if (instance == nullptr) 加锁后检查的经典写法（double-checked locking）在 C++11 之前是危险的，因为编译器重排和 CPU 乱序执行可能导致部分构造的对象被其他线程看到。C++11 起，标准库提供了真正安全的方案。
常见错误现象：Segmentation fault 或访问未完全构造对象的成员函数，尤其在高并发初始化时偶发。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 永远不要手写 double-checked locking，哪怕加了
volatile或memory_order也难保万无一失 - 用
static std::once_flag flag配合std::call_once(flag, []{ instance = new Singleton(); }) - 把
instance声明为static inline（C++17）或放在函数内部（推荐），避免静态对象析构顺序问题 - 注意：
std::call_once是阻塞式同步，首次调用会等待初始化完成，后续调用直接返回
禁止在构造函数里调用虚函数或依赖其他单例
单例对象常在程序启动早期、全局对象初始化阶段被首次访问，此时其他静态对象可能尚未构造完毕。若构造函数中调用了虚函数或访问了另一个单例（比如日志器），极易触发未定义行为。
立即学习“C++免费学习笔记（深入）”；
使用场景：服务类单例（如 ConfigManager、DatabaseConnection）往往需要读配置或连数据库，但这些依赖本身也可能是单例。
实操建议：
- 构造函数只做最轻量初始化（如置空指针、设默认值），把实际加载逻辑延迟到首次
getInstance()后的init()方法中 - 避免在单例构造函数中调用任何虚函数——此时虚表还没完全就位，会调到基类实现甚至崩溃
- 如果必须依赖其他单例，确保它们的初始化顺序有显式控制（例如全部在
main()开始后手动创建），而非靠静态变量定义顺序
delete 析构函数 + private 构造函数还不够防拷贝
很多人以为把构造函数、拷贝构造、赋值运算符设为 private，再 delete 析构函数，就能彻底封死实例化路径。但 C++ 中仍存在绕过方式：placement new、memcpy 内存复制、继承后友元访问等。
性能 / 兼容性影响：过度防御可能让调试更困难（比如单元测试需要 mock 单例时无法继承），但生产环境漏掉任一拷贝路径都可能导致多个实例并存，破坏单例语义。
实操建议：
- 除了
delete拷贝/移动构造与赋值，还要把析构函数设为private，并在类内提供static void destroy()（可选） - 在类声明末尾加
= delete显式禁用所有隐式生成函数：Singleton(const Singleton&) = delete;等 - 若需测试，改用依赖注入替代全局单例访问，而不是开放构造权限
- 注意：C++20 的
consteval和模块化构建下，某些链接时优化可能暴露静态局部变量地址，慎用extern template导出单例
静态局部变量版本最简洁，但要注意 C++11 保证的初始化安全性边界
这是目前最推荐的写法：static Singleton& getInstance() { static Singleton instance; return instance; }。C++11 标准明确保证该静态局部变量的初始化是线程安全且仅执行一次的。
参数差异：它不支持传参构造（比如带配置文件路径），也不方便做失败重试或 fallback 初始化逻辑。
实操建议：
- 适用于构造开销小、无外部依赖、无需参数的单例（如工具类
StringUtils、Timer） - 若需参数，别硬塞进静态局部变量——改用带
std::call_once的延迟初始化版本 - 注意：该机制依赖编译器对静态局部变量的实现，GCC/Clang/MSVC 均已符合，但旧版 ICC 或嵌入式工具链可能不完全支持
- 不要在
dlclose()卸载的共享库中使用这种单例，卸载后静态局部变量状态丢失，再次加载会重建，违反进程级唯一性
最麻烦的地方不在写法，而在生命周期管理：单例析构时机不可控，且可能在 main() 返回后、全局对象析构期间才执行，此时依赖的资源（如日志系统）可能已销毁。真要稳妥，就得放弃“自动析构”，改用手动生命周期控制。
