Java继承的设计意图是建模“is-a”关系，实现类间层次化复用与多态基础；它要求语义清晰、契约稳定（满足里氏替换）、避免仅为代码复用或“has-a”关系而滥用，否则易致系统僵化、测试困难、修改牵一发而动全身。
Java继承的设计意图是建模“is-a”关系，实现类间层次化复用与多态基础。它不是为偷懒省代码而设，更不等于“能复用就该继承”。误用继承最典型的后果是系统僵化、测试困难、修改牵一发而动全身。
设计意图：明确的层级建模与多态前提
继承在语义上表达一种天然的、稳定的分类关系。比如：
• Animal → Mammal → Dog：符合现实世界的生物分类逻辑
• Shape → Rectangle → Square（需谨慎，见后文）
这种链条中，子类确实在概念上是父类的一种，且父类契约稳定——即里氏替换原则成立：任何父类出现的地方，子类都能安全替换。
同时，继承是Java多态的必要条件。没有继承（或接口实现），就无法发生向上转型、方法动态绑定等行为，也就谈不上运行时多态。
常见误用一：把“has-a”当成“is-a”
这是最普遍也最危险的误用。例如：
立即学习“Java免费学习笔记（深入）”；
- 让 User 类继承 BaseService，只为了复用其中的
save()或log()方法 - 让所有 POJO 都继承一个 BaseEntity，只为共享
id、createTime字段
这些场景本质是“User has a service capability”或“User has an id”，而非“User is a BaseService”。强行继承会污染领域模型，导致子类承担不该有的职责，也破坏封装性——子类被迫暴露父类内部细节（如缓存策略、事务边界）。
常见误用二：仅因复用代码而引入继承
当两个类只是偶然有相同方法（比如都需校验邮箱格式），不应为此创建父类。这类复用更适合：
-
提取工具类：如
Validator.email(String) -
定义接口 + 默认方法：如
Validatable.validate()（Java 8+） -
组合委托：子类持有一个
ValidationHelper实例并调用其方法
继承复用一旦固化，后续若某子类不需要该功能，就只能空实现或抛异常，违背开闭原则。
常见误用三：忽视构造与初始化顺序风险
子类构造器隐式/显式调用 super(...) 是强制的，但容易忽略两点：
- 父类若只有带参构造器，子类必须显式调用，否则编译失败
- 父类构造器中若调用了可被重写的方法（危险！），实际执行的是子类重写后的版本——此时子类字段尚未初始化，极易引发
NullPointerException或逻辑错误
示例：父类构造器中调用 initConfig()，而子类重写了它并访问了自身未初始化的 configMap，就会出问题。
常见误用四：滥用深层继承链
超过三层的继承（如 A → B → C → D）会带来明显副作用：
- 方法来源难以追溯：IDE跳转可能需穿越多个文件
- 单点修改影响面不可控：B类改动可能意外破坏D类行为
- 构造器链变长，初始化逻辑耦合加剧
更健壮的做法是：用接口定义能力契约，用组合封装通用行为。例如将“可审计”、“可版本控制”等横切关注点拆为独立组件，由业务类按需持有。
继承本身没有错，错的是脱离语义、忽略约束、放弃权衡的随意使用。真正稳健的设计，往往始于一句自问：“这个子类，在业务语言里，真的‘是一种’父类吗？”
