多重继承本身不是问题，问题在于掩盖职责不清、接口混杂和耦合过重；应优先用组合替代public多重继承，纯虚接口才适合virtual public多继承，且需严格按声明顺序初始化基类。
直接改代码不如先改设计意图——多重继承本身不是问题，问题在于它常被用来掩盖职责不清、接口混杂和耦合过重。真正可维护的改动，是从“让它能编译”转向“让人一眼看懂数据流和控制权归属”。
用组合替代 public 多重继承
当 Derived 同时继承 BaseA 和 BaseB，且两者都带状态（非纯接口），就该警惕：这本质上是在强行把两个独立对象的生命周期和内存布局绑死在一个类里。
- 把
BaseA和BaseB改成普通成员变量，显式持有指针或值对象 - 在
Derived中只暴露必要的转发接口，比如doA()内部调用m_a.doSomething() - 避免隐式转换（
Derived*→BaseA*）带来的地址偏移风险，也规避了构造顺序依赖
纯虚类才适合多继承，且必须加 virtual 继承
如果只是想实现多个契约（比如 Loggable + Serializable + Configurable），那应该用纯虚类 + virtual public 继承，否则菱形结构下连 operator new 都可能出错。
- 每个接口类只含 public 纯虚函数和虚析构，不含数据成员
- 继承时写
class X : virtual public Loggable, virtual public Serializable，哪怕当前没菱形，也为未来留余地 - 不加
virtual的多接口继承，一旦某天引入共同基类（比如都加了个CommonInterface），立刻触发二义性
解决名字冲突不能只靠 :: 限定
看到 d.BaseA::show() 或 d.BaseB::show() 就该停一下——这不是修复，是打补丁。说明设计时没想清楚“谁该负责展示”。
- 优先在派生类中重写同名函数，做语义明确的封装：
show_status()、show_config()，而不是让调用方自己选基类 - 若必须暴露底层能力，用
using BaseA::show;把重载集拉进来，再加新重载，比每次手动限定干净得多 - 检查是否真需要两个基类都提供
show()；大概率其中一个是误放的通用函数，该抽到工具类里
构造函数初始化列表必须按声明顺序写
Derived 声明为 class Derived : public BaseA, public BaseB，但初始化列表里写成 BaseB(b), BaseA(a) 不会报错，却会导致 BaseA 构造时读到未初始化的 BaseB 成员（尤其当它们共享资源时）。
- 初始化顺序永远由基类在冒号后出现的**声明顺序**决定，和初始化列表里的书写顺序无关
- 所有基类构造参数，应在初始化列表中严格按
BaseA、BaseB的声明顺序排列 - 更稳妥的做法：把基类成员封装进 private 命名字段（如
m_timer、m_network），用组合 + 延迟构造，彻底绕开初始化顺序陷阱
最常被忽略的点是：多重继承的维护成本不在语法层面，而在调试时无法快速判断一个 this 指针实际指向哪个子对象——尤其当涉及 dynamic_cast 或虚函数表跳转。与其花时间查内存布局图，不如从第一行代码就拒绝让一个类承担超过两种正交职责。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
