继承链超三层需警惕，易致职责混淆与维护困难；应优先组合替代继承，接口定义契约，抽象类共享逻辑但限单层；final用于明确无扩展意图的类或方法。
继承链超过三层就该警惕
Java里继承不是越多越好，深度超过 class A extends B extends C extends D 这种三层结构，往往意味着职责混淆或抽象失当。编译器不拦你，但后续修改时，super.super.method() 这种调用几乎无法维护，子类对父类的隐式依赖也会越来越脆弱。
实操建议：
- 用
javap -c查看字节码，确认实际方法分派路径——如果发现INVOKESPECIAL频繁跨多层，说明继承已成负担 - 把“是”关系（is-a）严格限定在领域模型顶层：比如
AdminUser是User，但AdminUserWithExportPrivilege就不该再继承AdminUser，而应组合ExportCapability - IDE里按住 Ctrl（或 Cmd）点击父类名，如果跳转后看到 5 个以上未被重写的空方法或仅含
throw new UnsupportedOperationException()的桩，这就是抽象过度的信号
用组合替代继承时怎么选接口还是抽象类
关键不在“要不要抽象”，而在“谁负责决定行为契约”。如果能力模块需要强制实现某些方法（比如必须提供 serialize() 和 validate()），用接口；如果还要共享默认逻辑（比如日志埋点、重试封装），优先用抽象类，但只允许单层继承。
常见错误现象：NoClassDefFoundError 在运行时爆发，往往是因为抽象类里引用了子类尚未加载的静态资源，而接口不会触发这种初始化顺序问题。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 定义能力模块时，先写接口，再补一个
DefaultXxxService抽象类（带protected工具方法），让具体类选择继承或仅实现接口 - 避免在抽象类构造器里调用
protected abstract方法——子类字段可能还未初始化，JVM 不报错但值为null或0 - 接口方法加
default要克制：一旦多个 default 方法互相调用，又在不同实现类中被重写，调用栈会绕晕人
final 类和方法在继承控制中的真实作用
final 不是“防篡改保险柜”，而是明确告诉协作者：“这里没有扩展意图”。很多团队滥用 final 拦截继承，结果导致测试时只能用 PowerMock 拦截 new，反而增加耦合。
