@Override注解虽非强制，但能防止虚假重写：若签名不一致（如参数类型错位、泛型擦除导致隐形不匹配）、父类方法为private/static/final，或未正确继承接口，默认编译通过却无法实现多态，bug隐蔽难查。
不加 @override 注解，方法照样能“跑起来”，但很可能根本没重写成功——只是同名、同返回值、甚至看着像，实则被编译器当作全新方法处理。这种虚假重写不会报错，却让多态失效，bug 隐蔽难查。
参数类型错一位，重写就失效
Java 方法重写的前提是签名完全一致：方法名 + 参数类型（含顺序）+ 参数数量。只要其中一项不匹配，哪怕只是 int 写成 Integer、List<String> 写成 ArrayList<String>，编译器就不会认为这是重写，而是新增方法。
- 父类定义：
void process(List<String> items) - 子类误写：
@Override void process(ArrayList<String> items)→ 编译直接报错：“未重写任何超类型方法” - 若去掉 @Override：
void process(ArrayList<String> items)→ 编译通过，但运行时调用父类方法，逻辑静默跳过
泛型擦除导致的签名“隐形不一致”
Java 泛型在字节码中被擦除，但编译期仍严格校验原始类型。接口或父类方法若声明为 <T> void handle(T obj)，子类实现时若指定具体类型如 @Override void handle(String obj)，会因类型变量与具体类型不兼容而失败。
- 正确做法：保持泛型结构一致，或使用通配符约束（如
void handle(? extends String)不合法，需回归原始泛型声明） - 排查技巧：在 IDE 中按住 Ctrl（或 Cmd）点击父类方法名，确认其完整签名，尤其注意类型参数是否带通配符或边界
IDE 自动生成才是防错底线
手写重写方法极易出错，尤其是参数多、嵌套深、泛型复杂时。不要靠肉眼比对，要依赖工具保障一致性。
- IntelliJ：右键 → Generate → Override Methods，勾选目标方法，自动生成签名完全匹配的框架
- Eclipse：右键 → Source → Override/Implement Methods，自动补全并加 @Override
- 禁用“手动敲 @Override + 手写方法体”的开发习惯，把它视为高危操作
访问权限与 final/static 的隐性拦截
@Override 失败不一定源于签名，也可能是父类方法本身不可重写：
- 父类方法是 private：子类中同名方法不是重写，而是独立新方法（private 方法不可见、不可继承）
- 父类方法是 static 或 final：@Override 会直接编译失败，因为这两类方法禁止重写
- 父类方法是 default（接口默认方法），但子类在 JDK 8+ 下未显式继承该接口：无法重写，需确认 implements 关系完整
