构造函数初始化列表能绕过默认构造+赋值的双重开销，直接调用目标类型构造函数；const成员、引用、无默认构造的基类必须用初始化列表；初始化顺序严格按声明顺序而非列表顺序。
构造函数初始化列表能绕过默认构造 + 赋值的双重开销
对于类类型成员，如果在构造函数体中用 = 或 assign() 赋值，编译器会先调用其默认构造函数，再调用赋值运算符——哪怕你根本不需要那个“中间状态”。初始化列表直接调用目标类型的构造函数，一步到位。
常见错误现象：std::vector<int> data;</int> 在类中声明后，在构造函数里写 data = std::vector<int>(1000, 42);</int>，实际触发了默认构造（分配空内存）+ 移动赋值（或拷贝赋值），比 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++免费学习笔记（深入）”；
- 即使你试图在构造函数第一行赋值，也无效——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并在初始化列表中调用，同样踩中该陷阱
成员声明顺序、初始化顺序、依赖关系这三者一旦错位，问题往往静默发生，调试成本远高于写的时候多看两眼。
