选型核心是语义是否成立：继承表达is-a关系且须满足里氏替换，组合表达has-a/uses-a关系；继承需父类明确支持，否则易出错；组合应通过private final字段、接口依赖和行为委托实现松耦合、易测试、可替换。
选型核心不在语法能不能写，而在语义是否成立——组合与继承本质是两种不同关系的建模方式。用错关系，耦合度自然升高；用对了，结构才松散、可测、易替换。
先看语义：问一句“它是不是一种？”
继承表达的是is-a关系，必须满足里氏替换原则：任何使用父类的地方，都能无缝换成子类。比如Dog extends Animal合理，因为狗确实是一种动物；但Car extends Engine就荒谬——汽车不是发动机的一种，而是“拥有”发动机。
组合表达的是has-a或uses-a关系，强调能力委托而非类型归属。常见信号包括：
- 类名之间读不出“是一种”，但能自然说出“有一个”或“依赖一个”
- 复用目的只是调用某功能，而非扩展其类型体系
- 需要运行时切换实现（如测试时换 Mock，生产时切支付渠道）
再查父类：它真的欢迎被继承吗？
即使语义成立，继承也未必安全。Java 中大量类并未设计为可继承，强行 extends 很容易埋雷：
立即学习“Java免费学习笔记（深入）”；
- 父类 JavaDoc 没写 “This class is designed for inheritance”
- 关键方法是
final，或内部逻辑强依赖 private 字段和隐式调用顺序 - 像
String、LocalDateTime这类不可继承，不是限制你，而是它们的状态契约太脆弱，子类根本无法维持 - 父类有大量
protected成员，但文档没说明哪些可重写、哪些不能动
一旦发现这些迹象，哪怕“Dog is a Animal”再合理，也要警惕——这不是语义问题，而是父类不具备安全继承的工程条件。
组合要真正“组合”，不是简单塞个字段
组合不是把对象 new 出来塞进字段就完事，关键是委托行为 + 控制可见性：
- 用
private final字段持有依赖，构造器注入，避免 null 和后期篡改 - 对外只暴露你需要的能力，不泄漏底层实现（如
Stack不该暴露add()、get()等List接口） - 依赖尽量声明为接口（如
DataSource而非MySQLDataSource），方便替换 - 避免在组合链上深度调用（如
a.getB().getC().doX()），这会把空指针风险和耦合层层传递
性能与演化：组合更可控，继承更脆弱
有人担心组合多一层委托调用影响性能，实际影响微乎其微，反而带来长期收益：
- 继承在编译期绑定，父类一改（哪怕只是加个 protected 字段），所有子类可能编译失败或行为突变
- 组合在运行期绑定，底层实现可随时换成
ArrayList→LinkedList→ 自定义缓存列表，只要接口一致，上层完全无感 - 单元测试时，组合对象可直接 mock 或 stub；而继承的子类往往要绕过父类构造器、模拟 protected 方法，测试成本陡增
- Java 单继承限制下，组合支持一个类灵活接入多个能力（如同时持
PaymentProcessor和NotificationSender）
