std::call_once + static local variable 是当前最优解，因其线程安全、零开销、无双重检查缺陷，且比手写DCLP更简洁可靠，避免崩溃与垃圾值问题。
为什么 std::call_once + static local variable 是当前最优解
因为 C++11 起，静态局部变量的初始化天然线程安全，且由编译器保证只执行一次、无双重检查开销。比手写 std::mutex + 双重检查锁定（DCLP）更简洁、更可靠，也比老式“静态指针 + 构造函数判断”少掉坑。
常见错误现象：手写 DCLP 时忘记 volatile（其实没用）、memory_order 乱设、或漏掉 std::atomic_thread_fence，导致多线程下构造未完成就返回裸指针——程序偶发崩溃或读到垃圾值。
实操建议：
- 直接用
static T& instance()返回静态局部对象引用，别 new、别用指针存 - 确保类构造函数不抛异常；若可能抛异常，首次调用会失败且后续调用永远返回
std::terminate - 不要在构造函数里调用本类其他静态方法——可能触发未定义行为（初始化顺序不确定）
static local variable 单例的生命周期和析构风险
静态局部变量在首次调用时构造，程序退出时按逆序析构（即后构造先析构），但析构时机不可控，且跨 DLL/so 边界时可能被提前销毁。
立即学习“C++免费学习笔记（深入）”；
使用场景：适合进程内长期存活、无需显式销毁控制的服务类（如日志器、配置管理器）；不适合需在 main() 结束前手动清理资源（如释放共享内存、关闭监听 socket）的场景。
实操建议：
- 如果必须控制析构时机，改用
static std::unique_ptr<t></t>+std::call_once，并在合适位置调用reset() - 避免在析构函数里调用其他单例——它们可能已被销毁，引发访问已释放内存
- Windows 下 DLL 中的静态局部变量，若被多个模块引用，可能有多份实例（One Definition Rule 不保）
如何让单例支持继承和多态？
不能直接让基类模板化返回子类实例，否则破坏单例语义；也不能靠虚函数实现“运行时决定类型”，因为单例本质是编译期绑定的全局入口。
真正可行的做法是把“类型选择”上移到创建点，而不是藏在 instance() 内部。
实操建议：
- 用工厂函数替代通用
instance()，例如Logger& get_logger(LoggerType t)，内部用static局部变量分类型缓存 - 若需统一接口，让所有子类实现相同基类，并用
std::unique_ptr<base>存储，但注意：每个子类仍需独立的instance()函数 - 别试图用模板参数推导单例类型（如
Singleton<t>::instance()</t>），这会导致每个T都有一份静态变量，不是“一个进程一个实例”
为什么不用 std::shared_ptr 管理单例生命周期？
因为 std::shared_ptr 的引用计数本身不是无锁的，且每次拷贝/赋值都带原子操作开销；更重要的是，它无法防止用户意外调用 reset() 或赋值为 nullptr，从而破坏单例唯一性。
性能影响：在高频调用 instance() 的场景（比如每帧日志），shared_ptr 拷贝比引用返回慢 2–3 倍（实测 clang 15 / x86-64）。
实操建议：
- 坚持返回引用（
T&），禁止暴露原始指针或智能指针给外部 - 如果真要动态替换实现（如测试时 mock），用依赖注入代替单例，或在单例内部用
std::unique_ptr+set_impl()接口（需加锁） - 别为了“看起来更现代”而用
shared_ptr，C++ 单例的核心诉求是确定性、零成本抽象、线程安全，不是资源托管
最易被忽略的一点：单例的头文件里不能有非内联的静态数据成员定义——否则链接时可能报 ODR violation。所有状态必须封装在静态局部变量内部，或用 inline static（C++17 起）声明。
