根本上要切断跨模块初始化依赖链，因Windows下各DLL的static初始化由独立CRT控制、无跨模块同步机制，且链接顺序、init_priority、init_seg等均无法解决此问题。
跨 DLL 的静态变量初始化顺序问题无法靠“控制链接顺序”或“加初始化标记”解决，根本上要切断跨模块的初始化依赖链。
为什么 DLL 之间 static 初始化顺序不可控
Windows 下每个 DLL 有独立的模块初始化阶段（DllMain 中 DLL_PROCESS_ATTACH），但 C++ 全局对象的动态初始化时机由 CRT 控制，且标准不保证不同 DLL 中 static 对象的初始化先后。哪怕你把 libA.dll 链在 libB.dll 前面，libB 里某个全局 Config 对象仍可能在 libA 的 Logger 构造完成前就调用 Logger::instance() —— 因为它们属于不同翻译单元，且 CRT 初始化顺序与模块加载顺序不严格同步。
- 即使两个 DLL 都用 /MT 静态链接 CRT，各模块的全局对象初始化仍各自触发，无跨模块同步机制
-
__attribute__((init_priority))在 Windows MSVC 上无效，GCC/Clang 的该扩展也不跨 DLL 生效 - 试图用
#pragma init_seg调整初始化段，仅影响同一模块内顺序，对 DLL 间依赖无帮助
用 local static 替代全局 static 对象
把跨 DLL 依赖的“单例”或“配置对象”从全局变量改为函数内局部静态变量，利用 C++11 要求的线程安全惰性初始化语义。
- 错误写法：
Logger global_logger;放在logger.dll中，Config在config.dll构造函数里直接访问它 - 正确写法：在
logger.dll导出函数中定义Logger& get_logger() { static Logger instance; return instance; } - 调用方必须通过函数调用获取实例，不能取地址或声明 extern 全局引用
- 注意：
get_logger()本身不能被其他 DLL 的全局构造函数直接调用（比如写成auto& l = get_logger();在另一个 DLL 的全局作用域）—— 这仍是跨模块静态初始化依赖
避免在 DLL 的全局构造函数中调用其他 DLL 的 API
这是最常被忽略的隐式依赖点。哪怕你没显式写 extern，只要全局对象构造函数里调用了跨 DLL 函数，就可能触发未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 典型陷阱：
std::ofstream构造时内部依赖std::locale，而std::locale的全局 facet 初始化可能尚未完成 - 日志库中
static std::mutex成员，若其构造函数间接调用了HeapAlloc或 CRT 内部锁，而该 DLL 尚未完成 CRT 初始化，则可能死锁或崩溃 - 解决方案：所有跨 DLL 调用（包括 STL 对象构造）必须推迟到
DllMain返回后，即程序进入主逻辑之后；可借助std::call_once+ 懒加载标志位做二次防护
导出初始化函数，由主程序显式控制启动顺序
放弃“自动初始化”，改用显式、可排序的初始化入口，是最可控的工程实践。
- 每个 DLL 提供
void init_module_xxx()导出函数，内部完成所有静态资源初始化（如日志器、连接池、配置加载） - 主程序（EXE）按明确依赖顺序依次调用这些函数，例如先
init_logger()，再init_config()，最后init_database() - 确保这些函数只被调用一次（可用
static bool inited = false; if (inited) return; inited = true;简单防护） - 关键点：所有跨 DLL 的对象访问，必须发生在这些初始化函数返回之后；禁止在任何全局变量定义/构造中触发它们
真正棘手的地方不在“怎么写初始化函数”，而在于所有参与模块都必须遵守同一套契约：不暴露全局对象、不隐式触发跨 DLL 调用、不假设其他模块已就绪。一旦某个第三方库或旧代码偷偷在 .cpp 文件顶部写了 SomeClass g_instance;，整个链条就可能断裂。
