不能依赖。C++标准规定跨编译单元的全局变量初始化顺序未定义，链接器不保证file1.cpp中变量一定先于file2.cpp初始化；其顺序受链接命令、构建系统、LTO等影响，易导致未定义行为。
不能依赖。C++标准明确禁止跨编译单元（即不同源文件）的全局变量初始化顺序作为程序逻辑基础——它未定义，行为不可预测。
为什么链接器不保证 file1.cpp 的全局变量一定先于 file2.cpp 初始化
初始化顺序由链接器处理，但标准不约束其行为。即使你用相同编译器、相同构建参数反复编译，只要涉及多个 .cpp 文件，global_a 和 global_b 的构造先后就可能因以下原因翻转：
- 目标文件在命令行中传给链接器的顺序（如
g++ file1.o file2.o -o appvsg++ file2.o file1.o -o app） - 构建系统（CMake/Make）生成的中间文件命名或并行编译引入的时序扰动
- 启用 LTO（Link Time Optimization）后，链接器可能重排初始化逻辑
一旦某个全局对象的构造函数里访问了另一个跨文件定义的全局对象，而后者尚未完成动态初始化（比如 std::string 构造、自定义类构造），就会读到未定义值——不是 0，不是空，是内存垃圾，且调试器常显示“看起来正常”，实际运行崩溃。
extern + 全局赋值是最容易踩的坑
这种写法看似无害，实则高危：
立即学习“C++免费学习笔记（深入）”；
// config.cpp std::string g_config_path = "/etc/app.conf"; // logger.cpp extern std::string g_config_path; Logger g_logger(g_config_path); // ❌ 可能调用未构造完成的 string 对象
问题不在 extern 声明本身，而在 g_logger 的构造时机完全脱离控制。即使 g_config_path 是 constinit 或 constexpr，只要 Logger 构造函数里做了任何非常量操作（比如打开文件、解析路径），就落入动态初始化阶段，顺序即失控。
常见误判点：
- “我在头文件里加了
#pragma once就安全” → 不影响跨文件初始化顺序 - “我用 CMake 设置了 target_sources 的顺序” → 控制的是编译顺序，不是链接/初始化顺序
- “Debug 版本一直没问题” → Release 版本可能因优化触发不同初始化路径
用函数局部静态变量替代跨文件全局依赖
这是 C++11 起最可靠、最轻量的解法，利用“首次进入函数时初始化，且线程安全”语义：
// config.h
std::string& getConfigPath();
// config.cpp
std::string& getConfigPath() {
static std::string path = "/etc/app.conf"; // ✅ 首次调用时才构造
return path;
}
// logger.cpp
Logger g_logger(getConfigPath()); // ✅ 安全：调用时 path 已就绪
关键点：
- 不要把
getConfigPath()放进全局变量初始化表达式里（如auto& p = getConfigPath();），那又回到跨单元依赖问题 - 若需提前确保初始化（例如为 signal handler 准备资源），可显式在
main()开头调用一次该函数 - 对类类型，同样适用：
static MyService& instance() { static MyService s; return s; }
静态成员跨文件初始化失败的典型表现
当 A::s_value 依赖 B::s_data，而两者分属不同源文件时，错误往往不直接 crash，而是表现为：
-
std::cout << A::s_value;输出 0 或乱码，但B::s_data实际已被设为 42 - ASan 报告“use-of-uninitialized-value”，指向
B::s_data的读取位置 - 在 Windows 上用 MSVC 编译时正常，Linux + GCC 下偶发失败（链接器策略差异）
根本原因：静态成员变量本质仍是全局对象，受同一套跨编译单元顺序规则约束。别被 :: 语法迷惑——A::s_value 和 B::s_data 在链接视角下就是两个独立的全局符号，谁先构造，没商量。
