C++11起，static局部变量实现单例最安全，因其初始化线程安全且仅一次，避免DCLP错误、析构顺序问题及模板滥用风险，推荐无参instance()接口并禁用拷贝/移动。
为什么直接用 static 局部变量实现单例更安全
C++11 起，static 局部变量的初始化是线程安全的，且只会执行一次。这是最简、最可靠的方式，比手写双重检查锁（DCLP）更少出错。很多封装类试图“通用化”单例，反而引入静态对象析构顺序、模板实例化爆炸或内存泄漏风险。
常见错误现象：std::call_once 配合 std::once_flag 写法冗余；手动管理 new 出来的指针导致忘记 delete 或析构时机不可控；模板参数带非默认构造参数时编译失败。
- 使用场景：需要全局唯一、延迟初始化、线程安全访问的资源管理器、配置加载器、日志器
- 性能影响：
static局部变量首次调用有轻微开销（原子检查），后续无额外成本 - 兼容性：C++11 及以上完全支持，无需额外依赖
Singleton 模板类应只做一件事：提供 instance() 接口
不要试图在模板里控制生命周期、注册销毁钩子或支持多实例变体。那不是单例，是对象工厂的雏形。一个干净的封装只需暴露获取实例的入口，并确保构造逻辑不被重复触发。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 模板参数
T必须可默认构造（否则static T instance{}编译失败） - 禁止拷贝和移动：在类内声明
Singleton(const Singleton&) = delete;等 - 返回引用而非指针，避免空指针误判和裸指针管理负担
简短示例：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template <typename T>
class Singleton {
public:
static T& instance() {
static T inst{}; // C++11 线程安全初始化
return inst;
}
private:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};
当 T 需要构造参数时，别硬塞进模板
模板本身无法在运行时传参，强行设计带参数的 instance(args...) 会导致每次调用都尝试重新构造（违反单例语义），或引入静态局部 std::optional<T> + 手动 emplace，徒增复杂度和出错可能。
正确做法：把参数传递逻辑前置到首次调用前，比如用 init 函数或依赖注入容器。
- 错误写法：
Singleton<Database>::instance("host", 3306)—— 编译不过，且语义混乱 - 推荐方式：在
main()或模块初始化处调用Database::init("host", 3306)，再通过无参instance()获取 - 若必须延迟构造且带参，改用函数对象封装（如
std::function<T()>注册工厂），但已超出单例范畴
注意静态存储期对象的析构顺序问题
多个单例之间若有依赖（如 Logger 依赖 Config），它们的析构顺序由定义顺序决定，而跨编译单元时顺序未定义。这不是模板封装能解决的，而是链接期行为。
容易被忽略的地方：
-
static T inst{}的析构函数会在main()返回后、全局对象析构阶段执行 - 若某单例在析构时访问另一个已被销毁的单例，就会出现未定义行为（UB）
- 没有银弹方案，只能靠人工约定初始化/销毁顺序，或改用“显式销毁”模式（不依赖静态析构）
真正复杂的点从来不在怎么写模板，而在如何让多个单例彼此“不知道对方存在”。
