必须将跨模块静态变量改为函数内局部静态变量封装，因DLL加载顺序不确定导致STL对象构造时依赖未就绪（如locale、堆），引发崩溃或死锁；单例须用Meyer惯用法并避免构造函数中调用其他模块单例。
跨模块（尤其是 DLL/so）工程中，静态变量初始化顺序陷阱不是“能不能避免”的问题，而是“不处理就大概率崩溃或死锁”的问题——根本原因在于：不同模块的全局对象构造时机由加载顺序决定，而 CRT 初始化、locale 构造、堆管理器就绪状态等底层依赖又未被标准化约束。
std::ofstream 或 std::locale 在 DLL 中构造失败
典型现象是 DLL 加载时 std::ofstream 构造函数内部调用 std::locale，但该 locale 的 facet 尚未注册；或 std::mutex 构造时尝试调用 HeapAlloc，而 CRT 堆尚未初始化。这类崩溃往往发生在 DllMain 执行期间，无法捕获异常，调试器也难定位。
- 所有涉及 STL 对象（
std::ofstream、std::mutex、std::string等）的静态定义，必须从文件作用域移出，改用函数内局部静态变量封装 - 禁止在
DllMain里做任何非 trivial 的 C++ 对象构造；仅允许使用 Windows API 和纯 C 函数 - 若必须导出日志句柄，提供
getLogger()函数，内部用static Logger& instance = *new Logger()+std::call_once手动控制，绕过自动析构逻辑
跨 DLL 单例相互调用导致未定义行为
比如 Config::getInstance() 构造函数里调用 Logger::getInstance().log()，而 Logger 模块尚未完成初始化。此时不是“谁先谁后”的问题，而是链接器根本不会保证两个 DLL 的静态初始化阶段存在可预测时序。
- 单例必须用 Meyer 惯用法：
static T& get() { static T instance; return instance; }，C++11 起线程安全且延迟到首次调用 - 禁止在单例构造函数中调用其他模块的单例函数；若必须通信，改为回调、消息队列或弱引用（
std::weak_ptr） - 对强依赖关系，显式拆解为两阶段：先
initEarly()（只做内存分配、句柄获取），再finalize()（访问其他模块单例）
类静态成员跨编译单元初始化失败
常见于头文件中声明 static std::string s;，然后在多个 .cpp 文件里分别定义并初始化（如 std::string MyClass::s = getValueFromConfig();）。一旦 getValueFromConfig() 依赖另一个模块的静态对象，就触发 SOOF（Static Initialization Order Fiasco）。
立即学习“C++免费学习笔记（深入）”；
- 把所有非 constexpr 静态成员移到函数作用域，例如：
static std::string& getStaticString() { static std::string s = getValueFromConfig(); return s; } - 整型常量优先用
static constexpr int X = 42;，避免动态初始化阶段介入 - C++20 起可用
constinit强制静态初始化阶段完成，但注意它不替代const，也不提供线程安全
真正危险的不是“初始化晚”，而是“初始化过程中间接触发了未就绪的系统资源”——比如一个 std::ofstream 构造时悄悄拉起整个 locale 初始化链，而那个链依赖的 DLL 还没加载完。所以隔离方案的核心不是排序，而是切断初始化链：让对象诞生时间明确推迟到主逻辑可控之后，并用 std::call_once 或局部静态变量做二次防护。
