继承层次过深会直接削弱代码可读性、可调试性和运行效率，典型信号包括调用路径模糊、执行类型难确认、资源开销反常，如ide跳转失焦、jit拒绝优化、测试假覆盖及隐式依赖蔓延。
继承层次过深会直接削弱代码的可读性、可调试性和运行效率。问题往往不显山露水，但一旦爆发，就表现为“明明改了一行，测试全挂”或“压测时cpu突然飙升”。识别它，关键不是数有多少个extends，而是观察三类典型信号：调用路径模糊、执行类型难确认、资源开销反常。
看方法调用是否总在猜“到底执行了谁的”
当IDE按 Ctrl+Click 只跳转到父类声明，而不是实际运行的方法体；或者跳转后弹出多个候选实现（尤其在Spring AOP、Mockito代理、接口默认方法场景下），说明多态已脱离静态结构控制。此时继承链越长，歧义越多。
- 在关键入口方法第一行加
System.out.println(getClass())，比画UML图更快定位真实类型 - 断点设在最上层公共方法（如
process()），而非某个抽象基类里——避免被“看似进入、实则跳过”的重写逻辑绕晕 - 调用栈中频繁出现
$$EnhancerBySpringCGLIB或Proxy$类名，意味着AOP/事务等增强已介入继承链，静态分析完全失效
查对象创建和方法调用是否有异常延迟
不是所有慢都来自算法，有些慢是构造器层层调用、字段重复初始化、虚函数表线性查找堆出来的。尤其在高频循环或短生命周期对象场景下，损耗会被放大。
- 用JVM参数
-XX:+PrintCompilation观察热点方法是否长期无法JIT编译——深继承常因类型不稳定被JIT拒绝优化 - 新建一个子类实例，在调试器中展开其字段，检查是否携带大量未使用的父类成员（比如子类只用颜色，却继承了坐标、缩放、旋转、图层ID等）
- 对同一方法做10万次调用压测，对比直接调用子类实例 vs 父类引用调用，耗时差异超过5%即需警惕动态绑定开销
验测试覆盖与变更影响是否失控
继承链越长，单元测试越容易“假覆盖”：测了父类路径，漏了子类特有分支；改了祖父类，不敢确定哪些子类会意外崩溃。
- 运行覆盖率报告，重点看子类重写方法的行覆盖——若显示“已覆盖”，但实际只走通了父类空实现或默认逻辑，就是危险信号
- 修改一个基类字段的默认值，观察CI流水线中哪些测试用例非预期失败；如果失败范围远超直系子类，说明隐式依赖已蔓延
- 尝试给某一层中间类加
final（Java）或sealed（C#），编译报错数量暴增，证明该层已被下游当作“事实接口”滥用
这些问题不是孤立出现的。当你发现调试要靠日志盲猜、压测CPU热点在invokevirtual指令、改个getter都要开评审会——那基本可以确定，继承深度早已超出合理边界。
