方法重载发生在同一类中，靠参数列表不同实现编译时多态；方法重写发生在子类对父类同签名方法的覆盖，实现运行时多态。
方法重载（Overload）和重写（Override）看起来都叫“同名方法”，但它们发生的场景、编译器/运行时的处理方式、以及语义完全不一样——混淆这两者，轻则编译报错，重则逻辑出 bug，尤其在多态调用或泛型推导时容易掉坑。
重载发生在同一个类里，靠参数列表区分
重载是编译期行为，只看引用类型和实参的静态类型。只要 方法名相同 且 参数个数、类型或顺序不同，就构成重载；返回类型、访问修饰符、异常声明都不参与判断。
常见错误现象：
• 写了两个仅返回类型不同的方法（如 int getValue() 和 String getValue()），编译直接报错「重复的方法」
• 在子类中试图“重载父类方法”却改了参数类型（比如父类是 void process(List，子类写了 void process(ArrayList），这确实是重载，但调用时可能因类型擦除或泛型推导失效而意外走错分支
实操建议：
• 用 IDE 的 “Find Usages” 查看某个方法被哪些重载版本调用，比靠记忆靠谱
• 避免靠自动装箱/拆箱或隐式类型转换来区分重载（如 void f(int) 和 void f(Integer)），JVM 会优先选基本类型版本，容易误判
• 参数为泛型时，注意类型擦除后是否真能区分（如 void m(Object)，不构成重载）
立即学习“Java免费学习笔记（深入）”；
重写必须满足签名一致，且受访问权限和异常约束
重写是运行期行为，依赖对象的实际类型。子类方法要重写父类方法，必须满足：方法名、参数列表、返回类型（协变允许子类型） 完全一致；同时不能比父类更严格地限制访问（如父类 protected，子类不能写 private）；抛出的检查异常不能新增，只能缩小或删除。
常见错误现象：
• 子类方法加了 @Override 注解但编译报错，大概率是参数类型没对齐（比如父类是 CharSequence，子类写了 String）
• 父类方法声明抛出 IOException，子类重写时抛出 Exception，编译失败
• 用了 default 方法但忘了接口里不能有 static 重写（Java 8+ 接口中的 static 方法不可重写）
实操建议：
• 所有重写方法强制加 @Override 注解，让编译器帮你校验签名一致性
• 返回类型用协变时，确保子类返回类型是父类返回类型的子类（如父类返回 Object，子类可返回 String；但反过来不行）
• 接口默认方法被实现类重写时，不能降低可见性（接口中 public default，实现类也必须是 public）
重载和重写的调用路径完全不同
重载方法的选择在编译期完成，取决于变量声明类型；重写方法的执行在运行期决定，取决于对象实际类型。这是理解多态的关键分水岭。
示例代码清晰展示差异：
class Animal { void speak() { System.out.println("Animal"); } }
class Dog extends Animal {
@Override void speak() { System.out.println("Woof"); }
void bark() { System.out.println("Bark!"); }
}
class Test {
static void call(Animal a) { a.speak(); } // 运行时绑定，输出 Woof
static void call(Dog d) { d.bark(); } // 编译期绑定，只认 Dog 类型
public static void main(String[] args) {
Animal a = new Dog();
call(a); // 调用第一个 call(Animal)，再触发 speak() 重写 → Woof
// call(a); // 如果取消注释这行，编译失败：没有 call(Animal) 版本匹配
}
}
性能影响：
• 重载无额外开销，纯编译期决策
• 重写涉及虚方法表（vtable）查找，现代 JVM 通过内联和去虚拟化优化得极好，一般无需担心，但反射调用 Method.invoke() 会绕过这些优化，明显变慢
最容易被忽略的是：重载解析发生在编译期，所以泛型类型参数、类型推断结果、甚至 var 的推导结果，都会直接影响最终调用哪个重载版本；而重写只看运行时对象，跟声明类型无关。这两个机制一旦混用（比如在泛型方法里做重载分发），很容易出现“明明传了 String 却调到了 Object 版本”的情况。
