多层继承需按业务语义逐级抽象，每层只封装本层共有特征，明确职责边界，构造链须显式可控，谨慎使用protected与重写，统一继承Object但应重写toString和equals等方法。
多层继承的基本结构要清晰分层
多层继承不是简单套娃，而是按业务语义逐级抽象。比如动物体系中，Animal 是顶层通用类（有 name、eat、sleep），Mammal 继承 Animal 并增加哺乳行为（如 feedMilk），Dog 再继承 Mammal 并添加吠叫、捡球等特有功能。每一层只封装当前层级共有的特征，避免把孙子辈才用的逻辑提前塞进爷爷类。
每层类都要明确自己的职责边界
设计时需问三个问题：这个类是否真的“是一种”它的父类？它新增的行为是否只属于这一层？它的属性和方法是否会被下一层稳定复用？
- 若某个字段仅 Dog 用得上，就不该放在 Mammal 中
- 若 eat() 在 Animal 中是通用逻辑，但 Dog 需要特殊实现，就重写，不修改父类
- 避免在中间层（如 Mammal）强行加“会游泳”这种非所有哺乳动物共有的行为——那是 Seal 或 Dolphin 的事，应通过接口或组合补充
构造链必须显式可控
多层继承下，子类构造器默认只调父类无参构造器。一旦某层（比如 Mammal）只提供带参构造器，Dog 的构造器就必须用 super(...) 显式调用，否则编译失败。
- 推荐在每层父类提供一个带参构造器 + 一个调用它的无参构造器，降低下游使用门槛
- 不要依赖编译器自动插入 super()；主动写出来，让继承链意图一目了然
- 若某层需要初始化关键状态（如 Animal 的 species 字段），应在构造器中完成，而非靠 setter 补救
谨慎处理 protected 成员与方法重写
protected 成员可被任意子类访问，但多层之后容易失控。比如 Animal 定义了 protected String habitat，Mammal 没动它，Dog 却意外修改了它——外部调用者根本看不出这个值在哪一层被改过。
立即学习“Java免费学习笔记（深入）”；
- 优先用 private + public getter/setter 控制访问，比裸露 protected 更安全
- 重写方法时遵守里氏替换原则：Dog 对 speak() 的重写，不能让原本依赖 Animal.speak() 的代码出错
- 用 @Override 显式标注重写，避免因方法签名微小差异（如参数类型擦除）导致静默失败
顶层统一继承 Object，但别滥用它的方法
所有类最终都间接继承 Object，意味着天然拥有 toString()、equals()、hashCode() 等。但这些方法默认行为往往不适用。
- 只要类有业务身份（如 Person、Order），就该重写 toString() 和 equals()/hashCode()
- 避免在深层子类里重新定义 finalize()（已废弃）或 clone()（除非真需要浅拷贝且声明了 Cloneable）
- 若某类纯作数据载体（如 DTO），考虑用 record 替代传统继承结构，更简洁
