构造函数初始化列表必须用于const成员、引用类型及无默认构造函数的类成员，语法为冒号后接成员名与参数，顺序按类中声明顺序执行，而非列表书写顺序；它直接调用构造函数，避免默认构造+赋值的额外开销。
构造函数初始化列表怎么写才不报错
初始化列表不是可选项，而是某些成员必须用它初始化的唯一途径。比如 const 成员、引用类型、没有默认构造函数的类类型成员——这些在进入构造函数体前就必须完成初始化，否则编译直接失败。
常见错误现象：error: uninitialized const member 或 error: uninitialized reference member，本质是试图在函数体内用赋值语法（=）去“初始化”它们，但这时对象已经生成，只能赋值，不能初始化。
- 语法格式固定：冒号后跟成员名和括号内参数，多个用逗号分隔，例如
MyClass(int x) : a(x), b(42), ref(other_var) { } - 顺序按成员在类中声明的顺序执行，不是按初始化列表里写的顺序——这点容易踩坑，尤其当初始化依赖关系存在时
- 基类构造必须出现在初始化列表最前面（如果需要显式调用），否则会先调默认构造再覆盖，可能引发未定义行为
为什么用初始化列表比在函数体里赋值更快
关键区别在于：初始化列表调用的是成员的构造函数；而函数体内的赋值（member = value;）先调默认构造，再调赋值运算符——多了一次无谓的对象构建和析构。
对内置类型（int、double）影响几乎为零，但对自定义类型，尤其是带资源管理（如 std::vector、std::string）的类，开销明显。例如 std::vector<int> data;</int> 在初始化列表中写 data(100)，直接构造 100 元素；若在函数体中写 data = std::vector<int>(100);</int>，先默认构造空 vector，再移动赋值，至少多一次内存分配/释放。
立即学习“C++免费学习笔记（深入）”；
- 编译器未必能优化掉这个冗余步骤，尤其当赋值运算符非
noexcept或含副作用时 - 对于移动语义不完善的旧代码，性能差距更显著
- 初始化列表还能避免临时对象构造，比如
Person(std::string n) : name(std::move(n)) { }比name = std::move(n)少一次字符串拷贝
哪些情况初始化列表反而会出问题
初始化顺序陷阱是最隐蔽的问题：即使你把 b 写在 a 前面，只要 a 在类里声明得更早，它就先被初始化。如果 b 的初始化依赖 a 的值，而 a 还没构造完，结果就是未定义行为。
典型错误现象：程序偶发崩溃、成员值为垃圾数据、ASan 报 use-of-uninitialized-value。
- 永远按类中成员声明顺序书写初始化列表，别靠位置蒙混过关
- 避免在初始化列表中调用虚函数——此时虚表还没完全设置好，实际调的是基类版本
- 不要在初始化列表中抛异常后还指望后续成员能被析构（它们根本没构造成功），RAII 资源需用
try-catch块包裹整个构造函数
初始化列表和 delegating constructor 的配合
当多个构造函数逻辑高度重合，想复用初始化逻辑时，C++11 允许一个构造函数委托另一个（delegating constructor）。但注意：委托必须是初始化列表的唯一内容，且不能和其它初始化并存。
错误写法：A(int x) : a(x), A() { } —— 编译失败，不允许混合委托和其他初始化。
- 正确写法：
A(int x) : A() { a = x; }（委托默认构造，再在函数体赋值）或A(int x) : A(x, 0) { }（委托另一个带参构造） - 委托构造函数本身仍要走一遍初始化列表，所以被委托的构造函数的初始化列表才是实际生效的
- 性能上，委托不额外增加开销，但要注意它不会跳过任何初始化步骤——只是把控制权交给另一个构造函数
const 成员编译失败，或调试发现 vector 多分配了一次内存，才真正记住它该在哪用、怎么用。 
