跨DLL工程中static变量初始化顺序不可控是确定性问题，根本解法是改用函数内static局部变量延迟初始化，或提供显式init/shutdown接口由主程序控制顺序。
跨 DLL 工程中，static 变量初始化顺序不可控是确定性问题，不是概率性 bug——只要存在跨模块构造依赖，就大概率在某个环境（如 Release + LTO、特定 Windows 版本、DLL 加载顺序变化）下崩溃或死锁。根本解法不是“调顺序”，而是切断初始化链。
为什么 __attribute__((init_priority)) 和 #pragma init_seg 在 DLL 里完全无效
MSVC 忽略 __attribute__((init_priority))；#pragma init_seg 只能调整同一 DLL 内部的初始化段顺序，对跨 DLL 调用毫无作用。每个 DLL 的 CRT 初始化是独立触发的，DllMain(DLL_PROCESS_ATTACH) 返回后才开始执行该模块的全局对象构造函数，但这个“开始时间”本身就不受主程序控制。
- 现象：你在 libA.dll 里给
Logger加了init_priority(100)，libB.dll 的Config仍可能在Logger构造前调用Logger::instance() - 原因：libB.dll 的全局构造函数执行时，libA.dll 的 CRT 初始化阶段可能尚未完成，甚至
DllMain都没返回 - 验证方式：在两个 DLL 的全局变量构造函数里加
OutputDebugString，用 Process Monitor 观察加载和初始化实际时序
把全局 static 对象全改成函数内 static 局部变量
这是 C++11 起最轻量、线程安全、且无需额外同步的解法。核心是让初始化时机从“进程启动期”推迟到“首次调用时”，彻底避开链接/加载顺序问题。
- 错误写法：
Logger g_logger;+Logger& get_logger() { return g_logger; } - 正确写法：
Logger& get_logger() { static Logger instance; return instance; } - 若需参数（如配置路径），写成：
static Logger instance(path);，由调用方传入，不引入新依赖 - 必须返回引用（
Logger&），不能返回值（会拷贝）或指针（可能悬空） - 禁止在
get_logger()函数体外取地址、声明extern Logger& g_logger或在其他全局作用域直接调用它
绝对不要在全局构造函数里调用其他 DLL 的函数
哪怕只调了一行 std::cout << "hello"，也可能触发未定义行为——因为 std::cout 本身是动态初始化的全局对象，其关联的 std::locale facet 可能还没注册。
立即学习“C++免费学习笔记（深入）”；
- 典型崩溃点：
std::ofstream构造时内部调用std::locale::facet，而该 facet 在另一 DLL 中初始化；std::mutex构造时尝试调用HeapAlloc，但 CRT 堆尚未就绪 - 隐式调用比显式更危险：
class Config { Config() { log("init"); } };—— 这个log若来自另一 DLL，就已踩雷 - 安全替代：调试阶段用
fprintf(stderr, ...)，它不依赖 C++ I/O 流的全局状态；生产环境统一走函数内static封装的日志接口 - DllMain 中只允许纯 C 函数和 Windows API，禁止任何 C++ 对象构造（包括
std::string、std::vector）
导出显式初始化函数，由主程序控制启动顺序
放弃“自动初始化”的幻想。所有跨 DLL 依赖的模块，必须提供 init() 和 shutdown() 函数，由主程序按明确拓扑顺序调用。
- 示例：
extern "C" __declspec(dllexport) bool logger_init(const char* config_path);，主程序先调logger_init，再调config_init - 配合
std::call_once做二次防护：即使被重复调用，也只执行一次真正初始化 - 避免析构顺序陷阱：显式
shutdown()比依赖全局对象析构更可控，尤其当涉及资源释放顺序时 - 注意：
atexit回调、信号处理函数等需要在main()之前就绪的场景，不能依赖此方案，应改用编译期常量或零初始化静态变量
最易被忽略的一点：STL 容器和流对象（std::string、std::ofstream、std::mutex）一旦出现在文件作用域，就自动成为跨模块初始化陷阱的载体——它们的构造函数可能间接依赖其他 DLL 的全局状态，而你根本看不到调用栈。唯一可靠做法，是把它们全部关进函数作用域里。
