多层继承调试关键在于定位运行时实际方法和类型：用IDE跳转到实现（Ctrl+Alt+B/Ctrl+Click）代替声明，入口处打条件断点查this.getClass()，调用栈中识别代理类与反射调用，辅以临时日志输出getClass()验证。
多层继承体系下调试难，核心在于调用链长、方法重写频繁、运行时实际类型不直观。关键不是“看继承图”，而是快速定位“当前执行的是哪个类的哪个方法”，以及“这个方法里调用的又是谁的实现”。
用 IDE 的“跳转到实际实现”代替“跳转到声明”
在调用处按 Ctrl+Alt+B（IntelliJ）或 Ctrl+Click（VS Code + Java Extension），直接跳转到运行时真正执行的方法体，而非父类中的抽象/默认声明。这对重写（@Override）、默认方法（default）、接口默认实现尤其有效。若跳转结果有多个，IDE 通常会列出所有可能实现——此时说明该调用存在多态歧义，正是排查点。
在关键方法入口打条件断点，打印实际 this 类型
不要只在父类方法设断点，而是在最上层被调用的方法（如 process()）入口加断点，并在 Debug 模式下查看 this.getClass().getName()。也可以在断点处添加日志表达式：System.out.println("Running as: " + this.getClass().getSimpleName());。这样一眼看出当前对象真实类型，避免凭继承图“猜”执行路径。
善用调用栈（Call Stack）反向追踪，重点关注“由谁触发”
断点命中后，展开左侧调用栈，逐层向上看：
- 每一帧的类名和方法名是否符合你预期的实际类型？
- 是否有意外的代理类（如 Spring CGLIB 生成的 UserService$$EnhancerBySpringCGLIB$$xxx）？这类类会拦截调用，但源码不可见——需检查是否启用了 AOP、事务、缓存等增强。
- 栈中是否出现 super.xxx() 或 Method.invoke()？这表示显式委托或反射调用，逻辑已脱离静态继承链。
临时加一行 “System.out.println(getClass())” 比读十遍继承图管用
当动态行为复杂、IDE 跳转失效或环境受限（如远程调试），在疑似分支点插入轻量日志：
- 放在构造器里，确认实例化类型；
- 放在重写方法第一行，确认是否被调用；
- 放在 if (this instanceof Xxx) 块内，验证类型判断逻辑是否生效。
