C++20模块是否仍存在static initialization order fiasco？需用单例模式吗？

结论：C++20模块并未完全消除static initialization order fiasco，部分场景下依然需要用单例模式替代模块顶层的全局对象。

模块对初始化顺序的改善 #

模块的import语句明确了编译依赖关系，C++20标准规定：如果模块M导入模块N，那么N的所有静态存储期对象的初始化（包括常量初始化和动态初始化）会在M的初始化开始前完成。这解决了有明确导入依赖的跨模块全局对象的初始化顺序问题。

比如：

// 模块B
export module B;
export int global_val = 42; // 动态初始化

// 模块A，导入B
export module A;
import B;
static int dependent_val = global_val * 2; // 保证global_val已初始化

这种场景下不会出现初始化顺序问题。

依然存在的风险场景 #

模块的规则无法覆盖以下情况，此时仍会触发初始化顺序问题：

1. 无依赖关系的模块之间
   如果两个模块互相不导入，也没有共同的导入依赖，它们的静态存储期对象初始化顺序是编译器未指定的。若其中一个模块的静态对象依赖另一个模块的对象，就可能访问未初始化的内存。
   示例：

   // 模块B
   export module B;
   export std::string global_str = "hello"; // 动态初始化
   

   // 模块A，未导入B但链接时包含B
   export module A;
   #include <string>
   extern std::string global_str;
   struct Foo {
       Foo() { /* 可能访问未初始化的global_str */ }
   };
   static Foo foo;
   

   这里A和B无导入依赖，foo的初始化可能早于global_str，导致未定义行为。

2. 同一模块内跨分区的静态对象
   模块可以由多个翻译单元（分区）组成，不同分区内的静态存储期对象初始化顺序是未指定的。若分区A的静态对象依赖分区B的对象，同样会有风险。

3. 动态初始化的模块顶层对象被非模块代码依赖
   如果存在未使用模块的遗留代码直接链接模块，且该代码的静态对象依赖模块的顶层动态初始化对象，由于没有import保证顺序，依然会出问题。

单例模式的适用场景 #

当你的模块顶层对象属于动态初始化（即需要运行时计算、构造函数有副作用等），且存在上述风险场景时，单例模式（延迟初始化）依然是可靠的解决方案：

// 模块B，用单例替代顶层全局对象
export module B;
#include <string>
export std::string& get_global_str() {
    static std::string str = "hello"; // 首次调用时初始化
    return str;
}

这种方式不管全局初始化顺序如何，都能保证对象在首次使用时完成初始化，彻底规避顺序问题。

无需单例的场景 #

如果模块顶层对象是常量初始化（比如constexpr对象、字面量初始化的基本类型），则不存在初始化顺序问题，无需使用单例。例如：

export module B;
export constexpr int global_const = 42; // 常量初始化，无风险

内容的提问来源于stack exchange，提问作者Константин Ван