构造函数初始化列表能绕过默认构造+赋值的双重开销，直接调用目标类型构造函数；const成员、引用、无默认构造的基类必须用初始化列表；初始化顺序严格按声明顺序而非列表顺序。

构造函数初始化列表能绕过默认构造 + 赋值的双重开销

对于类类型成员，如果在构造函数体中用 = 或 assign() 赋值，编译器会先调用其默认构造函数，再调用赋值运算符——哪怕你根本不需要那个“中间状态”。初始化列表直接调用目标类型的构造函数，一步到位。

常见错误现象：std::vector data; 在类中声明后，在构造函数里写 data = std::vector(1000, 42);，实际触发了默认构造（分配空内存）+ 移动赋值（或拷贝赋值），比 data(1000, 42) 在初始化列表中慢且多一次内存操作。

• 基本类型（int、double）无差别，但统一用初始化列表更一致
• 自定义类、std::string、std::vector 等标准容器收益明显
• 移动语义启用时，赋值可能转为移动，但仍多一次对象生命周期管理开销

const 成员和引用成员必须用初始化列表

const 成员变量和引用类型（T&）无法被赋值，只能在创建时初始化。构造函数体里写 member = value; 会编译失败。

典型报错信息：error: uninitialized const member 'X::c_' 或 error: uninitialized reference member 'X::ref_'。

• 即使你试图在构造函数第一行赋值，也无效——C++ 规定它们必须在进入函数体前完成初始化
• 基类子对象若无默认构造函数，也必须在初始化列表中显式调用其带参构造函数
• 初始化顺序严格按成员声明顺序，而非初始化列表中的书写顺序；顺序不一致容易引发未定义行为

避免在初始化列表中调用虚函数或依赖未初始化成员

初始化列表中调用虚函数不会触发动态绑定，而是静态绑定到当前类（或基类）的版本，因为此时派生类部分尚未构造。同样，若某成员 A 在初始化列表中依赖成员 B，而 B 在类中声明在 A 之后，则 B 尚未初始化——此时读取 B 是未定义行为。

例如：

class X {
    int a_;
    int b_;
public:
    X() : a_(b_ + 1), b_(42) {} // 错误：a_ 初始化时 b_ 还未构造
};

• 编译器通常不报错，但运行结果不可预测
• 调试时注意观察成员声明顺序，必要时重构依赖关系或改用构造函数体内延迟初始化（如用 std::optional）
• 对基类构造函数的调用也参与该顺序：基类先于派生类成员初始化

初始化列表中不能使用 this 指针访问成员函数或数据成员

在初始化列表执行期间，对象尚未完全构造，this 指针虽已存在，但通过它访问任何非静态成员（包括调用成员函数、读写数据成员）都是未定义行为——因为那些成员可能还没轮到初始化。

比如下面代码是危险的：

class Y {
    int x_;
public:
    Y() : x_(this->compute_default()) {} // ❌ compute_default 可能访问其他未初始化成员
    int compute_default() { return x_ * 2; } // x_ 此时未初始化，读取未定义
};

• 所有计算逻辑应确保只依赖参数、全局状态或已确定安全的常量表达式
• 若逻辑复杂，宁可放到构造函数体内，用局部变量暂存结果，再赋给成员
• lambda 捕获 this 并在初始化列表中调用，同样踩中该陷阱

成员声明顺序、初始化顺序、依赖关系这三者一旦错位，问题往往静默发生，调试成本远高于写的时候多看两眼。