静态局部变量虽线程安全但无法真正按需延迟初始化，且不可重置、不支持参数构造；应使用std::call_once+static std::once_flag配合unique_ptr实现安全延迟初始化。
为什么不能直接用静态局部变量
静态局部变量在 C++11 起确实线程安全初始化，但它的生命周期绑定到首次调用函数时——也就是说，getInstance() 一调就初始化，无法做到“真正按需延迟”。如果你的单例构造开销大，且某些执行路径永远不访问它，这就浪费了资源。
更关键的是：静态局部变量初始化后无法重置、无法注入 mock 实例（测试时很麻烦），也不支持带参数的构造（比如从配置文件读取参数后再构造）。
std::call_once + std::once_flag 怎么写才对
核心是把初始化逻辑拆成两步：声明指针 + 在首次调用时用 call_once 安全地 new 实例。注意必须用原始指针或 std::unique_ptr，不能用 std::shared_ptr 的 get() 做双重检查——那会引入竞态。
- 必须把
std::once_flag声明为static，否则每次调用都新建 flag，call_once失效 - 构造函数必须是
private，禁止外部 new；拷贝/移动构造和赋值全部delete - 返回引用比返回指针更安全（避免用户误删），但内部仍要用指针管理生命周期
class Config {
private:
Config() = default;
static std::unique_ptr<Config> instance_;
static std::once_flag init_flag_;
public:
static Config& getInstance() {
std::call_once(init_flag_, [] {
instance_ = std::make_unique<Config>();
});
return *instance_;
}
Config(const Config&) = delete;
Config& operator=(const Config&) = delete;
};
常见错误：双重检查锁定（DCLP）在 C++ 里容易翻车
有人想手动优化性能，写个 volatile 指针 + if-check + lock，但 C++ 的内存模型不保证这种写法安全：编译器重排、CPU 乱序执行都可能导致返回一个未完全构造的对象。即使加 std::atomic，漏掉合适的 memory order（比如 memory_order_acquire/memory_order_release）依然出错。
立即学习“C++免费学习笔记（深入）”；
std::call_once 内部已处理所有同步细节，没必要、也不建议自己实现 DCLP。
- 不要用
volatile替代原子操作 - 不要在
call_once回调外访问未初始化的指针（哪怕加了 if 判断） - 不要把
once_flag放在堆上或作为成员变量——它必须是静态存储期
析构时机与静态对象析构顺序问题
用 std::unique_ptr 管理实例，析构会在程序退出时自动发生，但顺序不可控。如果单例 A 依赖单例 B，而 B 的析构先于 A 运行，A 的析构函数里再访问 B 就是野指针。
解决办法只有两个：要么让它们不互相析构（比如 B 用 new 分配但永不 delete），要么显式控制销毁顺序（例如提供 shutdown() 手动调用）。后者更可控，但得记住调用——很多人忘了。
- 不要依赖静态对象自动析构来清理资源（尤其是跨 DLL 或 shared library 时）
- 如果单例持有文件句柄、线程、网络连接，最好提供显式
close()或shutdown() -
atexit()注册的函数执行顺序是后进先出，但和静态对象析构混用时行为难预测
真正难的不是怎么写线程安全的初始化，而是怎么让它的生命周期和整个程序的 shutdown 流程对齐。这点往往被忽略，直到线上 core dump 里看到 double-free 或 use-after-free。
