组合优于继承，因其避免强耦合、支持运行时替换、规避多继承陷阱且符合has-a语义；继承仅适用于is-a关系，否则易引发接口污染、二义性及维护困境。
组合能避免继承带来的强耦合
继承会让子类直接暴露基类的实现细节，比如 protected 成员、虚函数表布局、构造顺序等。一旦基类内部调整（如改 protected 变量名、重排成员顺序、加新虚函数），所有继承链上的子类都可能意外崩溃或行为异常。组合则完全隔离——Engine 类怎么改，只要 start() 和 stop() 接口不变，Car 就不受影响。
常见错误现象：class Car : public Engine 导致 Car 意外获得 Engine 的所有接口（比如 type 字段），用户误调用或依赖这些本不该暴露的细节；而组合下，Car 只能通过明确声明的接口（如 engine.start()）访问，天然限界清晰。
组合天然支持运行时行为替换
继承关系在编译期就固定死了，无法动态切换。但组合允许你在运行时换掉整个部件：比如把 Engine 换成 ElectricMotor，只要两者有共同接口（如都实现 start()），Car 无需修改就能工作。
- 用值语义组合（
Engine engine;）：生命周期绑定，简单安全，适合轻量、确定生命周期的部件 - 用指针/引用组合（
std::unique_ptr<engine> engine;</engine>）：支持多态和运行时替换，但需手动管理或依赖智能指针 - 别用裸指针 +
new：容易漏delete，引发内存泄漏
组合规避多继承与菱形继承陷阱
C++ 支持多继承，但实际项目中几乎没人敢用——因为一不小心就写出菱形继承，必须引入 virtual 继承来消歧义，底层对象布局复杂，sizeof 难预测，调试器常显示错乱的成员偏移。而组合不涉及任何继承语法，一个类可以同时持有 Engine、BrakeSystem、Navigation 等任意多个对象，互不干扰。
立即学习“C++免费学习笔记（深入）”；
典型踩坑点：class Car : public Engine, public BrakeSystem 表面上省事，实则埋下二义性隐患；换成 Engine engine; + BrakeSystem brakes;，每个部件职责分明，编译器也不会报 request for member ‘start’ is ambiguous 这类错误。
组合更贴近真实建模语义
“汽车有一个发动机”是自然语言中的 has-a 关系，强行写成 class Car : public Engine 意味着“汽车是一种发动机”，逻辑上荒谬。C++ 编译器不会拦你，但后续维护者看到这种继承会困惑甚至误改。
判断依据很直接：
- 如果想说“X 是一种 Y”，且 Y 能完整替代 X（比如
Student是一种Person，可传给任何接受Person&的函数）→ 考虑public继承 - 如果只是“X 用到了 Y 的能力”，Y 不构成 X 的本质身份 → 必须用组合
真正难处理的不是语法，而是设计意图模糊时的妥协：比如为了少写几行委托函数，把 Engine 的 start() 直接提升到 Car 公共接口里，看似方便，实则破坏了 Car 自身的抽象边界——下次加 HybridEngine 时，就得同步改所有提升过的接口。
