继承链过长会严重损害可读性、可维护性和测试性，引发脆弱基类问题、IDE跳转迷失、构造器风险及测试爆炸；应优先采用组合、接口、委托等更可控的替代方案。
继承链过长会让代码越来越难理解、修改和测试，不是“越深越好”，而是容易掉进设计陷阱。
可读性与可维护性急剧下降
当一个类要追溯5层甚至更多父类才能搞清某个方法从哪来、被改过几次，开发者就得不断翻源码、查文档、猜意图。字段和方法的来源变得模糊，谁覆盖了谁、谁又依赖了谁，很快变成“黑盒拼图”。
- IDE跳转容易迷失在层层super()调用里
- 修改某一层的protected方法，可能意外破坏下游N个子类行为
- 新增需求时不敢动中间层，只能在最顶层打补丁，导致逻辑分散、重复
脆弱的“脆弱基类问题”（Fragile Base Class Problem）
基类看似稳定，但只要它内部实现稍作调整（比如重写一个模板方法、改变初始化顺序、加个新钩子），所有子类都可能静默出错——编译不报错，运行时才崩。
- 父类构造器中调用可被重写的方法，子类可能在对象未完全构造好时就被执行逻辑
- 父类为扩展预留的hook方法，若文档没写清调用时机和约束，子类实现极易引发状态不一致
- Java中没有final-by-default机制，普通方法默认可被覆写，风险天然存在
测试成本指数级上升
每增加一层继承，组合爆炸就开始发生：不仅要测当前类，还要考虑它在不同父类状态下的表现；每个子类都要重跑全部父类测试用例，还可能因覆写引入新分支路径。
立即学习“Java免费学习笔记（深入）”；
- Mock测试困难——想隔离测试子类逻辑，却绕不开父类复杂的初始化或外部依赖
- 回归测试范围难以界定：改了GrandParent，到底要重跑哪些TestSuite？没人敢说清
- 覆盖率数据失真：看似覆盖了，其实只是走通了父类路径，子类特有逻辑仍空跑
替代方案更轻量、更可控
不是不能用继承，而是该用组合、接口、委托、策略模式的地方，硬套继承只会放大问题。
- 用接口定义能力契约（如Runnable、Comparable），实现类自由组合，不绑定结构
- 把共用逻辑抽成工具类或默认方法（Java 8+接口default），避免强制继承层级
- 用组合+委托替代“is-a”，比如Engine类作为字段注入到Car，比让Car extends Engine合理得多
- 必要继承时，把关键基类设为final，或至少把核心方法设为final，明确边界
基本上就这些。继承是工具，不是目标；链越长，离初衷越远。
