关于C++标准[basic.start.static]p.3动态初始化条件的技术疑问

先把标准条款的内容列出来（重点为提问者标注）：

在当前C++标准的[basic.start.static]第3款中规定：
允许实现将具有静态或线程存储期的变量的初始化作为静态初始化执行，即使此类初始化并非必须静态完成，前提是：

• 该初始化的动态版本在自身完成初始化前，不会修改任何其他具有静态或线程存储期的对象的值，并且
• 若所有无需静态初始化的变量都进行动态初始化，则该初始化的静态版本产生的变量值与动态版本产生的相同。[...]

下面逐个解答你的问题：

为什么第一个条件表述得如此具体？ #

这个规则本质是在给编译器开优化绿灯的同时，杜绝初始化顺序混乱导致的未定义行为。静态初始化是程序启动最早的一批操作（早于main，甚至早于某些运行时初始化），此时大部分其他静态/线程存储期对象还处于未初始化的状态。

如果某个变量的动态初始化过程中，在自己还没完全初始化好的时候就去修改其他静态对象，那一旦编译器把它改成静态初始化，这个修改动作的时机就被大幅提前——直接撞到了被修改对象的初始化之前，这会彻底打乱原本的依赖逻辑，产生完全不可预测的结果。

举个直观的例子：

// 动态初始化的全局变量
int global_b = 42;
// 如果这个被编译器改成静态初始化
int global_a = (global_b = 0, 10);

动态初始化时，global_b先被设为42，然后global_a的初始化把它改成0，最终global_b是0；但如果global_a被静态初始化，它会在global_b的初始化之前执行，global_b随后的初始化会把值设回42——两种场景结果完全相反，这显然违反了标准要保证的行为一致性。第一个条件就是为了把这种"在初始化过程中干扰未就绪对象"的情况彻底排除在外。

为什么动态版本完成初始化后修改其他静态对象是允许的？ #

当变量自身的初始化完成后，它已经处于稳定状态了。此时即使它修改其他静态对象，这个修改动作的相对时机逻辑在静态初始化替换后是可以保证一致的：

• 如果被修改的对象是静态初始化的，那它的初始化已经完成，修改动作不会破坏未初始化的对象；
• 如果被修改的对象是动态初始化的，那不管原动态初始化顺序如何，静态初始化的变量总是会在动态初始化之前完成，修改动作的顺序（自身初始化完成后）和动态场景下是一致的，最终结果也能符合第二个条件的要求。

比如这个例子：

int global_a = [](){
    int val = 10;
    // 自身初始化完成后才修改global_b
    global_b = 0;
    return val;
}();
int global_b = 42;

动态初始化时，global_a先执行，把global_b改成0，随后global_b的初始化把值设为42；如果global_a被静态初始化，它会在global_b的动态初始化之前完成，同样global_b最终会被自己的初始化为42——两种场景结果完全一致，所以这种情况是被允许的。

为什么动态初始化存在其他副作用是被允许的？ #

标准的核心关注点是变量的最终值是否符合预期，以及是否会破坏其他静态对象的初始化过程。只要这两个条件满足，其他不影响核心状态的副作用（比如打印日志、调用不碰静态对象的辅助函数、修改局部变量等），编译器是可以自由优化掉的。

毕竟允许静态初始化替换的初衷之一就是提升程序启动速度——静态初始化是编译期完成的，不需要在运行时执行复杂的代码逻辑。只要最终变量的值和动态初始化的结果一致，并且不会干扰其他对象的初始化，那些无关紧要的副作用有没有其实不影响程序的正确性。

比如这个例子：

#include <iostream>
int global_a = [](){
    std::cout << "Initializing global_a\n"; // 打印副作用
    int temp = 5;
    return temp + 5;
}();

编译器完全可以把global_a的初始化改成静态的直接赋值10，虽然打印的动作消失了，但global_a的最终值是对的，也没有干扰其他静态对象，这完全符合标准的规则。

内容的提问来源于stack exchange，提问作者user42768