组合比继承更安全、可控、易维护；java中真正需继承的场景极少，误用易致脆弱基类问题；组合显式依赖接口，利于测试与替换；继承仅适用于子类确为父类一种、父类专为继承设计且稳定、或框架强制要求等苛刻条件。
不是因为继承“不好”，而是组合在绝大多数实际场景中更安全、更可控、更易维护。Java 里真正需要继承的地方其实很少，而误用继承带来的问题却很常见。
继承容易让类之间绑得太死
子类一旦 extends 父类，就自动获得它的字段、方法、初始化逻辑，甚至构造顺序约束。父类加个 protected 字段、改个 init() 调用时机、重命名一个内部工具方法，都可能让子类悄悄出错——比如 NullPointerException 出现在构造器里，或者重写 toString() 时忘了 super 调用导致日志缺关键信息。这种“脆弱基类问题”排查起来特别费劲。
组合把依赖关系摆到明面上
- 你声明 private final PaymentProcessor processor;，就只依赖它公开的接口，不关心它内部是走支付宝还是模拟支付
- 测试时直接注入 MockProcessor，不用启动真实数据库或网络调用
- 运行时也能换实现，比如灰度阶段切一部分流量到新策略
- 多个类可以共享同一个组件实例，节省资源
语义错了，设计就容易歪
判断该用哪个，先读出来：“Car 是 Engine 吗？”显然不是；“Car 有一个 Engine”才自然。强行让 Car extends Engine 不但违反常识，还会让 Car 意外暴露 Engine 的所有方法（比如 start()、stop()），破坏封装，也违背里氏替换原则——你不能把 Engine 当 Car 用。
继承的适用条件其实很苛刻
只有同时满足这三点，才值得考虑继承：
- 子类确实是父类的一种（Dog 是 Animal，不是“Dog 有 Animal”）
- 父类明确为被继承而设计（有 protected 钩子、文档注明“可子类化”、提供模板方法）
- 父类本身稳定，不含易变的业务逻辑（比如 AbstractList 可以，ArrayList 就不该被继承）
框架强制要求（如 HttpServlet、JUnit TestCase）属于例外，但即便如此，现代做法也倾向在顶层加一层适配器，把业务逻辑和框架耦合隔开。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
