组合比继承更安全，因其将依赖控制在接口层，避免子类过度耦合父类实现；继承仅适用于明确“is-a”关系且父类专为继承设计的场景，框架强制要求时除外。
组合比继承更安全，尤其在需要灵活替换行为时
继承容易导致子类过度依赖父类实现细节，一旦父类修改，所有子类都可能出问题；组合则把依赖控制在接口或抽象层，行为变更只需换一个Component实例。比如你写一个PaymentProcessor，用继承就得为每种支付方式写一个子类（AlipayProcessor、WechatProcessor），而用组合只要注入不同PaymentStrategy实现即可。
常见错误现象：ClassCastException频发、父类protected字段被误改、子类重写toString()却忘了调用super.toString()导致日志丢失关键信息。
- 优先使用组合：把可变逻辑抽成接口，通过构造函数或setter注入
- 继承只用于“is-a”关系明确且父类设计为被继承（比如标记了
@MustOverride注释或文档说明） - 避免在父类中调用可被重写的
protected方法（如init()），否则子类构造时可能访问未初始化字段
继承在框架集成场景下仍不可替代
Spring MVC 的 @Controller 类必须继承 BaseController（如果团队统一封装了权限校验或日志模板），MyBatis 的 Mapper 接口虽不继承，但 XML 映射文件里用的 resultMap 本质是继承式复用——这些不是设计选择，而是框架契约强制要求的。
性能影响很小，但兼容性风险高：JDK 升级后，某些被继承的类（如java.util.AbstractList）内部实现可能调整，导致子类add()行为异常，而组合对象不受影响。
立即学习“Java免费学习笔记（深入）”；
- 框架要求继承时，别硬套组合；但可在继承链顶端加一层适配器，隔离业务逻辑与框架耦合
- 若父类没有
final修饰且未声明为abstract，默认就是开放继承的信号——但不等于鼓励你去继承 - 检查父类源码：是否有
template method模式（如execute()调用doExecute()），这是继承的合理使用痕迹
final 类和 private 方法让继承失效，组合反而更自然
Java 标准库大量使用final（如String、LocalDateTime），第三方库也越来越多把核心类设为final。这时候强行继承会直接编译失败，而组合天然适配这种封装策略。
容易踩的坑：有人用反射绕过final限制，或用字节码工具（如Byte Buddy）动态生成子类——这会让代码失去可读性和可维护性，CI 环境还可能因 JDK 版本差异失败。
- 遇到
Cannot inherit from final 'xxx'错误，第一反应不是找破解方案，而是定义自己的包装类，持有该final实例 - 组合时别盲目暴露所有委托方法，只暴露业务真正需要的，避免变成“胖包装器”
- 注意
hashCode()和equals()：组合类若参与集合操作，必须正确定义这两个方法，不能简单委托给内部对象（除非语义完全一致）
IDE 和静态分析能帮你发现继承滥用
IntelliJ 默认警告“Class extends a class with no public constructors”，SpotBugs 会报SE_BAD_FIELD（序列化字段非private）或IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION（父类构造中调用子类方法）。这些不是噪音，是真实的设计隐患。
一个典型信号：子类里出现大量super.xxx()调用，且每次都要加空判断或默认值处理——这说明父类契约太弱，不如拆成组合+策略接口。
- 启用 IDE 的 “Inheritance depth” 检查（建议阈值 ≤ 2），超过就该审视是否要引入中间接口
- 用
@Deprecated标注已不推荐继承的父类，并在 JavaDoc 里写明替代组合方式 - 测试时重点覆盖子类重写方法的边界条件，继承链越深，测试爆炸增长越明显
组合不是银弹，继承也不是毒药；但凡涉及未来可能变化的行为，或者你不完全掌控父类演进节奏，组合就是更稳的选择。最容易被忽略的是：组合带来的间接层，会让调试时多跳一次方法调用——别省略这个步骤，它恰恰是解耦的代价和证据。
