初始化列表是C++构造对象的核心机制，它直接调用成员/基类构造函数，避免默认构造与赋值开销；const和引用成员必须在此初始化；初始化顺序严格按声明顺序，而非列表顺序。
构造函数初始化列表直接调用成员的构造函数
普通赋值方式（在构造函数体内部用 = 或 operator=）会先默认构造成员对象，再调用赋值运算符；而初始化列表绕过默认构造，直接以参数调用目标类型的构造函数。这对自定义类型尤其关键——比如 std::string、std::vector 或用户定义类，避免了无意义的默认状态创建。
const 和引用成员只能通过初始化列表赋值
const 成员和引用类型没有默认可赋值的状态，编译器强制要求它们必须在初始化列表中完成初始化。如果试图在函数体内赋值，会报错：error: uninitialized const member 或 error: uninitialized reference member。这不是效率问题，而是语法硬性限制。
避免临时对象与多余拷贝/移动
考虑以下对比：
class Widget {
std::string s;
public:
// ❌ 先调用 string()，再调用 string::operator=(const char*)
Widget(const char* p) { s = p; }
// ✅ 直接调用 string(const char*)
Widget(const char* p) : s(p) {}};
立即学习“C++免费学习笔记（深入）”；
第一种写法中，s 先被默认构造为一个空字符串，再从 p 构造临时 std::string，最后执行移动或拷贝赋值；第二种跳过所有中间步骤。即使启用了 RVO 或移动语义，初始化列表仍更可控、更少依赖编译器优化。
常见误区包括：
- 以为
std::move能挽救函数体内的赋值效率——不能，因为默认构造已发生 - 对内置类型（如
int、double）过度纠结——它们无构造开销，但统一用初始化列表更一致、更安全 - 在初始化列表中按声明顺序以外的顺序书写——实际初始化仍按成员声明顺序进行，可能导致未定义行为（如用后声明的成员初始化先声明的成员）
继承链中基类构造也依赖初始化列表
派生类无法绕过基类构造：基类子对象必须在派生类成员之前构造，且只能通过初始化列表显式传递参数。漏写或写错基类初始化，会导致调用基类默认构造函数——这可能不符合设计意图，甚至引发逻辑错误（例如基类需要非空配置）。
例如：
class Base {
int x;
public:
Base(int v) : x(v) {}
};
class Derived : public Base {
std::string s;
public:
// ✅ 正确：Base(42) 在初始化列表中显式调用
Derived() : Base(42), s("hello") {}
// ❌ 错误：Base 将调用默认构造（若存在），否则编译失败
Derived() : s("hello") {} // error: no default constructor for Base};
立即学习“C++免费学习笔记（深入）”；
初始化列表不是“性能锦上添花”，而是 C++ 对象生命周期控制的核心机制。跳过它，等于放弃对构造时序和资源初始化的精确掌控。
