Static initialization order fiasco 是指跨编译单元的 static 变量初始化顺序未定义，导致依赖调用时出现未定义行为；Construct on First Use 通过函数局部 static 变量延迟构造并返回引用，确保首次访问时才初始化，从而规避该问题。

什么是 static initialization order fiasco？

当多个 static 变量（尤其是跨编译单元）的初始化相互依赖时，C++ 标准不保证它们的初始化顺序。如果 A 的构造函数调用 B::get()，而 B 尚未初始化，就会触发未定义行为——常见表现是程序崩溃、空指针解引用或读取垃圾值。

为什么 Construct on First Use 能规避这个问题？

核心思路是：把 static 对象的构造延迟到**第一次使用时**，而非翻译单元加载时。这样能确保每次访问都拿到一个已构造完成的对象，彻底绕过初始化顺序问题。

• 只对函数局部 static 变量有效（C++11 起保证线程安全初始化）
• 全局 static 或类静态数据成员仍受 fiasco 影响，不能直接用
• 每次调用函数开销极小（仅首次有构造成本，后续是纯指针返回）

如何正确实现 Construct on First Use？

必须用函数封装，且返回引用；不能返回值或指针（避免拷贝或悬空）；函数体里声明局部 static 变量。

MyClass& getMyInstance() {
    static MyClass instance;  // ✅ 延迟构造，C++11 线程安全
    return instance;
}

• 错误写法：static MyClass* p = new MyClass(); —— 内存泄漏风险，且无法控制析构时机
• 错误写法：return MyClass(); —— 返回临时对象，调用者拿到的是已销毁对象的引用
• 若需自定义构造参数，可传入函数参数并缓存（如 static MyClass instance(arg);）

它不能解决哪些问题？

Construct on First Use 是“访问时保障”，不是“启动时保障”。如果你的逻辑依赖某个对象在 main() 之前就绪（比如用于全局 atexit() 回调、信号处理函数中访问），它就无能为力。

• 静态对象的析构顺序仍是反向初始化顺序，和构造顺序无关
• 若两个函数互相调用对方的 “on-first-use” 函数（A 调 B，B 又调 A），会引发死锁或未定义行为
• 频繁调用该函数的性能敏感路径，需确认编译器是否内联了返回引用的操作（通常会）

真正棘手的地方往往不在“怎么写”，而在“要不要写”——有些模块看似需要全局单例，实则可通过依赖注入或显式生命周期管理更清晰地解耦。