委托构造函数不执行成员初始化，所有字段初始化仅在最终被调用的构造函数中完成；析构顺序严格逆于构造顺序，成员析构按声明逆序而非初始化列表顺序；虚继承下虚基类由最派生类直接构造；接口调用顺序不可靠，需显式状态管理。
委托构造函数的调用顺序必须由被委托方完成初始化
委托构造函数本身不执行成员初始化，所有字段初始化只发生在最终被调用的那个构造函数中。如果你在委托方的函数体里访问未初始化的成员，会触发未定义行为。
常见错误现象：member variable used without being initialized 或运行时读取垃圾值；本质是误以为委托构造函数的初始化列表也生效了。
- 委托语法只能出现在初始化列表中，形如
ClassName() : ClassName(other_args) { } - 被委托的构造函数必须完整执行（包括其初始化列表 + 函数体），之后才进入委托方的函数体
- 一个构造函数最多委托一次，且不能出现在任何其他初始化逻辑之后
- 若需多阶段初始化，应把共用逻辑抽到私有辅助函数，而非依赖委托链顺序
析构顺序与构造顺序严格相反，封装时需预判资源释放时机
类中成员对象的析构顺序固定为声明顺序的逆序，和初始化列表顺序无关。这点在封装接口时极易被忽略——尤其当接口暴露了资源句柄或回调注册机制时。
使用场景：你封装了一个 DatabaseConnection 类，内部持有一个 std::mutex 和一个 FILE*。若声明顺序是 FILE* fp; 在前、std::mutex mtx; 在后，则析构时 mtx 先销毁，fp 后关闭。此时若析构函数里有加锁操作，就会 crash。
立即学习“C++免费学习笔记（深入）”；
- 资源释放顺序无法通过调整初始化列表改变，只能靠调整成员声明顺序来控制
- 继承体系中，派生类析构函数先执行，基类析构函数最后执行；若基类析构函数非虚，通过基类指针 delete 派生对象会导致部分析构
- 对 RAII 类型（如
std::unique_ptr、std::thread），析构行为由其自身保证，但它们的销毁时机仍受上述顺序约束
虚继承下的构造顺序由最派生类直接控制，封装时要避免隐式依赖
当你在封装一个支持多继承的基类接口（比如 Serializable + Observable）并引入虚继承时，虚基类的构造函数不会由中间层调用，而是跳过中间类、由最终派生类直接调用。这打破了常规的“父类先于子类”的直觉。
容易踩的坑：你在 Serializable 中写了带参数的虚基类构造函数，却没在最终派生类的初始化列表中显式调用它，编译器会报错 call to implicitly-deleted default constructor —— 因为中间类不会帮你转调。
- 虚基类构造函数参数必须在最派生类的初始化列表中提供，中间类的初始化列表中写它会被忽略
- 多个虚基类按它们在类定义中首次出现的顺序构造，不是按继承声明顺序
- 如果封装的是模板基类（如
template<typename t> class Observable</typename>），虚继承时需确保所有特化版本都可被最派生类直接构造
接口函数体内调用顺序不可靠，应避免隐含执行路径依赖
封装接口时，不要假设 init() 一定在 start() 之前被调用，也不要让 start() 内部静默补全 init() 的工作。这种“自动补救”看似友好，实则破坏调用契约，增加调试难度。
典型问题：用户先调用 start()，再调用 set_option()，结果选项未生效。因为 start() 内部已触发状态机启动，后续配置被忽略。
- 明确划分“配置阶段”和“运行阶段”，用状态枚举或
std::optional成员标记是否已初始化 - 对非法调用（如未初始化就
start()）应直接抛出std::logic_error或返回std::errc::invalid_argument，而不是吞掉错误 - 若必须支持懒初始化，应在每次关键操作前检查状态，并统一由一个私有
ensure_initialized()执行，而非分散在各函数中
真正难处理的不是语法层面的调用顺序，而是当构造、析构、虚继承、接口调用四者交织时，那些隐藏在声明顺序、继承路径和用户调用习惯之间的耦合点。这些地方一旦出错，往往表现为偶发 crash 或资源泄漏，复现困难。
