c++标准不保证跨编译单元全局变量的初始化顺序，易导致未定义行为；推荐用static局部变量封装实现延迟、线程安全且可控的初始化。
全局变量跨编译单元的初始化顺序确实不确定
是的，C++标准明确不保证不同 .cpp 文件中定义的非局部 static 变量（包括全局变量）的初始化顺序。只要它们不在同一个编译单元里，谁先谁后完全由链接器和启动代码决定——不是随机，但不可控、不可移植、不可预测。
典型症状：std::terminate 或访问非法内存，尤其在构造函数里调用另一个全局对象的方法时；或者调试发现某全局 std::map 还没构造完就被别的全局对象往里插数据，直接崩溃。
- 只影响 不同翻译单元 之间的
static对象：同个.cpp文件里按定义顺序初始化，没问题 - 不影响
constinit（C++20）或constexpr变量：它们走常量初始化，早于动态初始化阶段 - 不影响函数内
static局部变量：首次调用才初始化，线程安全（C++11 起），且顺序明确
用 local static 变量替代全局对象是最常用解法
把全局变量封装进函数里，靠 static 局部变量延迟初始化，既解决顺序问题，又天然支持单例语义和线程安全。
// 坏：跨文件依赖，可能 crash
extern std::vector<int> g_config;
std::map<std::string, int> g_lookup = buildFrom(g_config); // g_config 可能还没初始化！
// 好：初始化时机可控，且只在首次需要时发生
const std::map<std::string, int>& getLookup() {
static const std::map<std::string, int> instance = buildFrom(getConfig());
return instance;
}
const std::vector<int>& getConfig() {
static const std::vector<int> instance = loadConfig();
return instance;
}
- 注意返回
const&，避免每次调用都拷贝 - 函数名要清晰表达“获取”，别叫
initXXX()，容易误导调用者手动触发 - 如果构造开销大且确定只用一次，可以加个
std::call_once+std::once_flag手动控制，但通常没必要——static局部变量已内置该机制
链接时初始化顺序 hack（不推荐，但得知道为什么不行）
有人试过用 __attribute__((init_priority))（GCC）或 #pragma init_seg（MSVC）强制排序。这些是编译器扩展，不是标准 C++，跨平台项目基本等于自埋雷。
立即学习“C++免费学习笔记（深入）”；
-
init_priority数值越小越早，但仅限同一编译单元内有效；跨文件仍不保证 - Windows 上
init_seg(.CRT$XCU)控制的是 CRT 初始化段，和用户全局变量不在一个层级，行为难预测 - 构建系统（如 CMake）无法可靠协调多个目标文件的优先级，CI 环境下极易出错
静态库里的全局变量更危险
静态库（.a / .lib）中未被直接引用的全局对象，可能被链接器整个丢弃——哪怕它有副作用（比如注册工厂）。这比初始化顺序问题还隐蔽。
- 确认是否被链接：用
nm -C libxxx.a | grep YourGlobalVarName查看符号是否存在 - 强制保留：GCC 加
-Wl,--undefined=YourGlobalVarName，或 MSVC 用/INCLUDE:YourGlobalVarName - 更稳妥的做法：把注册逻辑挪到显式调用的
init_XXX()函数里，由主程序控制调用时机
真正麻烦的从来不是“怎么让它动起来”，而是“怎么让别人改了 A 文件里的全局变量，却不小心破坏了 B 文件里看似无关的初始化逻辑”。这种隐式耦合藏得深，复现难，debug 成本远高于一开始就用函数封装。
