排查重载与重写错误的关键是显性化隐式行为：编译器报错可快速区分重载失败（如“no suitable method”）或重写失效（@Override 编译失败）；IDE 跳转验证是否真重写；注意参数类型字面一致、泛型擦除、自动装箱等陷阱；运行时用多态引用+日志/断点确认实际执行路径。
排查方法重载与重写调用错误，关键不是“猜逻辑”，而是用编译器和工具把隐式行为显性化。多数问题不是代码写错了，而是签名没对齐却误以为覆盖成功——尤其在多态场景下，看似调子类方法，实际执行父类空实现，bug静默且难复现。
看编译器是否报错，快速区分是重载失败还是重写失效
重载错误通常立刻暴露：
• 调用时提示 “no suitable method found” 或 “ambiguous method call” → 是重载歧义或无匹配版本
• 编译报 “duplicate method” → 参数列表实际相同（比如只改了参数名或顺序但类型未变）
重写错误更隐蔽：
• 没加 @Override 时，子类方法签名稍有偏差（如 int vs Integer、List vs ArrayList），编译器不报错，它默默当成新方法 → 运行时走父类逻辑
• 加了 @Override 却编译失败 → 真实签名不匹配，问题定位直接
用 IDE 跳转验证是否真在重写，而不是假覆盖
在子类方法名上按住 Ctrl（Windows/Linux）或 Cmd（macOS） 并点击：
• 能跳转到父类/接口中的原始方法 → 签名一致，是有效重写
• 跳不到，或跳到其他同名方法 → 实际是重载，或父类方法为 private/static/final（不可重写）
特别注意：
• 接口 default 方法需确认子类确实 implements 该接口，且 JDK ≥ 1.8
• 泛型方法要展开擦除后类型比对：void process(List<String>) 和 void process(ArrayList<String>) 擦除后分别是 List 和 ArrayList，不等价
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
检查参数类型细节，避开隐式转换陷阱
Java 重写要求参数类型**字面一致**，自动装箱、类型提升、泛型具体化都会破坏签名：
• 父类是 void handle(Integer x)，子类写 void handle(int x) → 基本类型与包装类不同，是重载
• 父类是 void parse(CharSequence s)，子类写 void parse(String s) → String 是 CharSequence 子类，但签名不等，仍是重载
• 父类是 <T> void sort(List<T> list)，子类写 void sort(ArrayList<String> list) → 类型擦除后前者是 List，后者是 ArrayList，不构成重写
立即学习“Java免费学习笔记（深入）”；
运行时验证多态行为，确认实际执行路径
别只看代码，要看对象真实类型如何绑定：
• 用父类或接口引用指向子类实例：Parent p = new Child(); p.method();
• 在 method() 中打日志或断点，确认进入的是父类还是子类方法体
• 若预期子类逻辑但执行了父类方法 → 大概率是重写未生效，回溯检查签名、@Override、访问修饰符（private/protected/public）、异常声明范围
