全局数组初始化时机取决于定义位置与初始化表达式：常量表达式触发静态初始化（main前完成），非常量表达式导致动态初始化（顺序不确定，跨编译单元有风险）；推荐用static局部变量封装延迟初始化以确保线程安全与确定性。
全局数组的初始化时机由定义位置决定
全局数组在 main 函数执行前完成初始化，前提是它被定义在所有函数外部（即命名空间作用域），且初始化表达式是常量表达式。编译器会在程序启动时、main 进入前，把这类数组的数据直接写入可执行文件的数据段（.data）或未初始化段（.bss）。
常见误区是以为“只要写在 main 外面就一定早于 main 执行”——其实不然：如果用非常量表达式（比如调用函数、访问未定义行为的变量）初始化，C++ 标准规定这是动态初始化，发生在 main 之前但顺序不确定，还可能跨编译单元引发静态初始化顺序问题。
-
int arr[3] = {1, 2, 3};→ 静态初始化，安全可靠，main前已就位 -
int arr[3] = {func(), 0, 0};→ 动态初始化，func()在main前被调，但若func依赖其他未初始化的全局对象，行为未定义 -
extern int arr[3];声明不触发初始化，定义处才决定时机
需要运行时计算？用 static local 变量模拟“延迟首次初始化”
如果数组内容必须靠函数计算（比如读配置、解析环境变量），又想确保只执行一次且在线程安全前提下早于 main 中首次使用，不能硬塞进全局数组初始化器，而应封装成函数返回引用：
const std::array<int, 3>& get_config_array() {
static const std::array<int, 3> result = []{
// 这里可调用任意函数、读环境变量等
return std::array<int, 3>{get_env_int("A"), get_env_int("B"), 42};
}();
return result;
}
这样做的好处是：C++11 起，static 局部变量的初始化是线程安全的，且仅在第一次调用该函数时发生；虽然不是严格“main 前”，但对绝大多数使用场景（比如 main 一进来就调用）效果等价，且规避了跨 TU 初始化顺序风险。
立即学习“C++免费学习笔记（深入）”；
- 不要用
static int arr[3] = {...}+ 非常量初始化器，这仍是动态初始化，不解决顺序问题 - 返回
const&避免拷贝，生命周期由静态存储期保证 - lambda 立即调用（IIFE）让初始化逻辑清晰内聚
跨编译单元时，别依赖全局数组初始化顺序
如果你有两个源文件，a.cpp 定义 int arr[2] = {init_x(), 0};，b.cpp 定义 int x = 42;，而 init_x() 返回 x，那结果未定义——因为 C++ 不保证不同翻译单元中非内联全局变量的初始化顺序。
- 同一 TU 内按定义顺序初始化，跨 TU 则不可预测
- 把依赖关系收束到一个 TU，或改用函数内
static变量（如上节方案） - 启用
-fno-common（GCC/Clang）和/Zc:externConstexpr（MSVC）可帮助检测部分违规
嵌入式或裸机环境需手动控制？靠链接脚本和构造器属性
在无标准库环境（如 freestanding），main 可能不是入口点，全局数组初始化由启动代码（crt0）调用 __libc_init_array 或类似函数完成。此时你无法绕过它，但可以干预：
- 用
__attribute__((constructor))（GCC/Clang）或#pragma init_seg（MSVC）注册初始化函数，它会在所有静态初始化之后、main之前运行 - 数组本身仍建议用静态初始化，构造器函数只做“填充后处理”，比如校验、映射到硬件寄存器
- 链接脚本中可将特定数组放入自定义 section（如
.mydata），再在启动代码中显式清零或复制
真正棘手的是：一旦初始化逻辑涉及浮点运算、内存分配或系统调用，在裸机上根本不可用——这时候所谓“main 前初始化”只是幻觉，得退回到汇编级或启动代码里手工处理。
