构造函数初始化顺序严格按成员声明顺序执行，与初始化列表书写顺序无关；const/引用成员必须在初始化列表中初始化，且依赖项须先声明；基类先于成员初始化，派生类构造函数体最后执行。
构造函数初始化列表的执行顺序不取决于写法，而取决于成员声明顺序
哪怕你在初始化列表里把 memberB 写在 memberA 前面，只要 memberA 在类定义中先声明，它就一定先被初始化。编译器会严格按成员变量在类中出现的物理顺序调用构造函数，和初始化列表里的排列无关。
常见错误现象：某个成员（比如 memberB）依赖前一个成员（memberA）的值做初始化，但你误以为初始化列表顺序决定执行顺序，结果传入了未定义值——因为 memberA 实际上还没构造完。
- 永远按类内声明顺序组织初始化列表，减少认知偏差
- 如果必须用
memberA初始化memberB，确保memberA声明在memberB之前 - 编译器不会报错，但 Clang 和 GCC 在
-Wall下会警告“field is initialized after field”，别忽略它
const 或引用成员必须在初始化列表中初始化，且只能靠声明顺序保障有效性
const 成员、引用成员（T&）、没有默认构造函数的自定义类型成员，无法在构造函数体内赋值，必须出现在初始化列表中。此时若它们依赖其他成员，而依赖目标在声明顺序上靠后，就会出问题——因为依赖项还没构造。
例如：const int size; 和 std::vector<int> data;</int>，你想用 size 初始化 data 的容量，就必须让 size 声明在 data 之前；反过来，data 就拿不到有效 size 值，可能触发未定义行为或编译失败（如 data(size) 中 size 是垃圾值）。
立即学习“C++免费学习笔记（深入）”；
- 把被依赖的成员放在前面声明，是唯一可靠的方式
- 不要试图用函数调用（如
init_size()）绕过——该函数若访问后面才声明的成员，仍是未定义行为 - 对于复杂依赖链，考虑拆成两阶段：先用 trivial 构造，再在
init()中补足逻辑
基类与成员的初始化顺序固定：基类 → 成员（按声明序）→ 派生类体
初始化顺序不是“列表优先级”，而是硬编码规则：先调用所有直接基类的构造函数（按继承声明顺序），再按类内成员声明顺序初始化每个非静态成员，最后才进入派生类构造函数体。这个顺序不可更改，也不受初始化列表影响。
容易踩的坑：在基类构造函数里调用虚函数，此时派生类成员尚未初始化，虚表还是基类的——但更隐蔽的是，在初始化列表中传入某个成员的地址给基类构造函数，而该成员在声明顺序中排在基类之后，那传进去的就是未构造的内存。
- 避免在基类构造中使用派生类成员的地址或引用
- 如果必须传递，确保该成员声明在基类继承语句之前（C++ 不允许，所以实际应避免）
- 初始化列表中对基类的初始化写法（如
Base(x)）只控制参数，不改变基类本身的初始化时机
调试时怎么看实际初始化顺序？加日志或断点最直接
没有宏或编译器指令能自动打印初始化顺序，但你可以给每个成员变量封装成带日志的包装类，或者在每个成员的构造函数里打日志。注意：日志输出本身不能依赖其他成员（否则又绕回顺序问题）。
一个轻量实操方式：对关键成员使用自定义类型，其构造函数接受字符串名并输出，比如：
struct LogInit { LogInit(const char* n) { std::cout << "init: " << n << "\n"; } };然后在类中声明为 LogInit a{"member_a"};、LogInit b{"member_b"};，运行就能看到真实顺序。
- 别依赖 IDE 的代码高亮或折叠顺序——它不反映编译器行为
- 单元测试中故意让后声明成员读取前声明成员的值，可快速暴露顺序误用
- 跨编译器行为一致，这是 C++ 标准强制要求，不是实现细节
成员声明顺序不是风格问题，是构造语义的一部分。改一个变量的位置，可能让原本工作的代码开始读取未初始化内存——而且没有任何编译错误。
