多层继承问题源于职责错位而非深度本身，应限制为两层（如animal→dog→servicedog），超深链需重构为接口+委托；基类须保持不可变契约，禁用protected可变字段；退化抽象层应及时清理。
多层继承本身不必然导致混乱，问题出在缺乏约束和职责错位。关键不是“能不能链得长”，而是“每一层是否真代表语义上的本质变化”。控制深度、明确边界、及时重构，比事后补救更有效。
把继承链硬卡在两层以内
这是最直接有效的防线。Animal → Dog 是一层；Dog → ServiceDog 是第二层，到此为止。再往下延伸（比如 ServiceDog → CertifiedServiceDog），大概率不是新类型，而是角色、配置或策略差异——此时应触发重构信号，而不是加子类。
- 团队规范中明确：所有具体实现类必须声明为 final，禁止被继承
- 用 SonarQube 或 IDEA 的 “Inheritance depth” 检查，在 CI 阶段拦截超深结构
- IDEA 中开启后，超过两层的类会标黄提示，便于早期发现
中间层抽象优先改用接口 + 委托
像 LoggingService、CachedService、ValidatedService 这类名字带 “Service” 的中间类，往往只是给多个子类“打补丁”，实际是能力装配职责，不是语义上的“是一种”。它们正是复杂度温床。
- 把 LoggingService 改成 Loggable 接口 + DefaultLogger 实现，由业务类通过字段持有
- 将 ValidatedService 抽成 ValidationRule 策略对象，构造时传入，而非继承固定逻辑
- 每个业务类只依赖所需能力，调用链清晰，单元测试只需 mock 单个组件
基类只保留不可变契约
父类一旦悄悄塞进可变细节（如默认数据库连接、硬编码重试次数、特定异常包装），子类就只能绕着走或强行覆盖，破坏封装。
- 基类中避免 protected 字段，尤其 List、Map 等可变容器——子类随意修改会导致状态不一致
- 拒绝业务逻辑渗透：校验规则、配置加载、线程模型等都应外置，不写死在父类里
- 若必须暴露方法给子类，用 protected 前务必加文档说明输入/输出/副作用
定期识别并清理退化层
有些抽象层已失去存在意义：子类多数只是透传 super.xxx()，或仅覆盖一两个空方法，这类“伪抽象”该合并就合并，该删就删。
- 在 IDE 中右键关键方法 → “Find Usages” → 切换到 “Hierarchy” 视图
- 若显示超 5 个子类且多为透传，说明该层已退化
- 结合类图观察扇出过高、空实现泛滥、子类雷同这些信号，启动重构
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
