Java中多态必须依赖方法重写，子类需用@Override正确重写父类非final/static/private方法，确保签名一致、返回类型协变、访问权限不更严格，否则动态绑定失效。
重写是实现多态的必要条件
Java 中的多态（运行时多态）必须依赖方法重写。没有 @Override 的子类方法，即使签名相同，也不会触发动态绑定；JVM 在运行时只会根据对象实际类型去查找被重写后的方法，而不是声明类型。
常见错误现象：Animal a = new Dog(); a.speak(); 输出的是 Animal 的实现，说明 Dog.speak() 没有正确重写 —— 很可能是参数列表不一致、返回类型不协变，或加了 static/private 修饰符。
-
final、static、private方法不能被重写，也就无法参与多态 - 重写要求子类方法签名（名称 + 参数类型）与父类完全一致，返回类型需是父类返回类型的子类型（协变返回）
- 访问权限不能比父类更严格（如父类
protected，子类不能写private）
编译期看引用类型，运行期看实际类型
多态行为在编译阶段只检查引用类型是否定义了该方法（即“能不能调”），而真正执行哪个版本，由堆中对象的实际类型决定。这个机制完全依赖 JVM 的虚方法表（vtable）和重写后的入口地址替换。
典型陷阱：List 中，list.add() 调用的是 ArrayList.add()，不是 List 接口里的默认方法（除非显式调用 List.super.add()）。接口方法默认不是虚方法调用目标，只有被类重写后才进入多态链。
立即学习“Java免费学习笔记（深入）”；
- 接口中的
default方法不参与子类对父类方法的重写逻辑，它属于“接口继承”，不是“类继承重写” - 若父类和接口都定义了同名同参方法，且子类未重写，则编译报错（歧义）
-
super.method()是静态绑定，绕过动态分派，不体现多态
重写失败时多态就失效
很多看似“像重写”的写法其实只是重载（overload）或隐藏（hiding），不会触发多态。例如子类写了 toString(String)，而父类是 toString()，这根本不是重写，只是新增了一个重载方法。
容易忽略的兼容性影响：Java 9+ 对 var 类型推导的支持不影响重写判断，但若使用泛型桥接方法（bridge method），编译器自动生成的桥接方法可能掩盖重写失败问题，需用 javap -c 查看字节码确认是否真有 invokespecial 或 invokevirtual。
- 父类方法抛出
IOException，子类重写时只能抛出IOException子类或不抛异常；否则编译失败，重写中断 - 泛型擦除后若签名冲突（如
set(List和) set(List），实际都变成) set(List)，会导致重写失败或编译错误 - 使用 Lombok 的
@EqualsAndHashCode或@Data时，若手动写了equals(Object)却没按规范处理null或类型转换，表面重写成功，实则破坏多态语义
class Animal {
public void speak() { System.out.println("Animal sound"); }
}
class Dog extends Animal {
@Override
public void speak() { System.out.println("Woof!"); }
}
public class Main {
public static void main(String[] args) {
Animal a = new Dog(); // 引用类型 Animal，实际类型 Dog
a.speak(); // 输出 "Woof!" —— 多态生效
}
}
重写不是语法糖，它是 JVM 动态分派机制的锚点。一旦重写契约被破坏（比如返回类型不协变、异常声明越界、甚至 IDE 自动生成时漏掉 @Override 注解导致隐式重载），多态就会静默退化为单态调用——而这种错误往往在测试覆盖不到的分支里才暴露。 
