继承问题源于误将其当作代码复用首选而非is-a关系建模工具，如stack继承vector破坏封装；应优先组合、慎用protected、避免构造器中调用可重写方法。
为什么 extends 一用就出问题？
Java 中继承本身没问题，但多数问题源于把 extends 当成“代码复用首选”，而不是“明确的 is-a 关系建模工具”。比如让 Employee 继承 Person 没问题，但让 Stack 继承 Vector（JDK 早期错误）就破坏了封装——子类被迫暴露父类所有 public 方法，哪怕语义上根本不该调用 removeElementAt()。
常见症状包括：NullPointerException 在父类构造器中调用被子类重写的 hook 方法、子类意外覆盖父类关键逻辑、final 修饰缺失导致不可控的重写。
用组合替代继承的实操要点
不是禁止继承，而是优先考虑组合。比如要实现一个带缓存的数据库访问器，别写 class CachedDao extends JdbcDao，而应：
- 定义接口
Dao，让JdbcDao和CachedDao都实现它 -
CachedDao内部持有一个Dao实例（如private final Dao delegate;），只在需要时委托调用 - 缓存逻辑完全隔离，不污染数据访问契约
这样既避免了继承链断裂风险，又便于单元测试（可注入 mock Dao）。
立即学习“Java免费学习笔记（深入）”；
protected 字段和方法是最大隐患源
很多继承问题实际来自滥用 protected。一旦父类暴露 protected List<string> items;</string>，子类就能随意修改，导致父类内部状态不一致。
更安全的做法：
- 把字段全设为
private，提供受控的protected方法（如protected void addItem(String item)）而非裸字段 - 若必须开放状态访问，返回不可变视图：
return Collections.unmodifiableList(items); - 考虑用
final修饰父类方法，或整个类（如public final class StringUtils），从源头封住继承可能
构造器里调用可重写方法为何危险？
这是最隐蔽也最常踩的坑。父类构造器执行时，子类字段尚未初始化，此时调用被子类重写的实例方法，很可能读到 null 或默认值。
示例：
class Parent {
Parent() {
init(); // 实际调用的是 Child.init()
}
void init() { }
}
class Child extends Parent {
private String config = loadConfig(); // 此时尚未执行
void init() {
System.out.println(config.length()); // NullPointerException!
}
}
解决方式只有两个：把 init() 设为 final，或改用工厂方法 + 显式初始化步骤（如 new Child().setup()）。
真正难处理的不是语法限制，而是团队对“继承即强耦合”的认知惯性——哪怕加了 @Deprecated 的 extends，只要编译通过，就有人会用。
