构造函数初始化列表的实际底层工作机制是什么

本质是C++对象构造的阶段划分规则决定的：构造函数体内的代码执行前，所有非静态类成员的初始化流程已经全部完成，你在构造函数体内写的const成员赋值属于"修改操作"，而非"初始化操作"，直接违反const的语义约束。

一个C++类实例的构造，严格按照以下顺序执行，不存在顺序调整的可能：

• 第一步：为整个实例分配对应大小的原始内存块，此时内存中的值都是未定义的垃圾值。
• 第二步：按照成员在类中声明的先后顺序（和初始化列表的书写顺序无关），逐个完成成员的初始化：
  • 如果你在构造函数的初始化列表中显式指定了该成员的初始化逻辑，就直接调用对应构造函数完成成员的构造。
  • 如果没有在初始化列表中指定，编译器会自动尝试调用该成员的默认构造函数完成构造；如果成员没有默认构造函数，直接触发编译错误。
• 第三步：上述所有成员构造完成后，才会进入构造函数的函数体，执行你写在大括号里的逻辑。

const修饰的变量核心语义是：仅允许在初始化阶段被赋值一次，初始化完成后全程只读，不允许任何修改操作。
等执行流走到构造函数体内时，const成员已经在第二步完成了初始化（哪怕你没写，编译器也会尝试给它做默认初始化，const内置类型默认初始化后的值是未定义的），这时候你再给它写赋值语句，本质是对一个已经初始化完成的const对象做修改，直接违反语言规则，编译器必然报错。
而初始化列表的逻辑是直接在第二步的成员初始化阶段执行，相当于从无到有构造const成员的时候就把目标值写进去，完全符合const的语义要求。

错误写法（构造函数体内赋值，编译失败）：

class Test {
private:
    const int m_const_val;
public:
    Test(int input) {
        // 此处是赋值不是初始化，执行到这里时m_const_val已经完成初始化，const对象不允许修改
        m_const_val = input;
    }
};

正确写法（初始化列表初始化，编译通过）：

class Test {
private:
    const int m_const_val;
public:
    // 初始化列表在成员构造阶段直接给m_const_val赋初始值，符合语义
    Test(int input) : m_const_val(input) {
        // 函数体内可以写其他和成员初始化无关的业务逻辑
    }
};

所有要求"必须在初始化阶段完成赋值"的成员，都不能在构造函数体内赋值，本质都是时序问题：

• 引用类型成员：引用必须在初始化时绑定目标对象，初始化后不允许改绑，构造函数体内的赋值属于改绑操作，语义不允许。
• 没有提供默认构造函数的自定义类型成员：如果不在初始化列表显式调用它的有参构造，第二步初始化阶段编译器会尝试调用它的默认构造，找不到就直接编译报错，等走到构造函数体时已经过了构造该成员的时机。

注意：不要把初始化列表的作用误解为"提升性能"。对普通可默认构造、可赋值的成员来说，用初始化列表确实可以省去"先默认构造、再赋值"的额外开销，但对上述三类成员来说，不用初始化列表是根本无法通过编译的，和性能无关。

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