@Override是编译期校验开关，要求方法名、参数类型、个数、顺序完全匹配父类或接口中非private/static/final方法，任一不匹配即报错“method does not override...”，强制修正签名。
编译器会直接报错，只要签名有一处不匹配
@Override 不是装饰，是校验开关。Java 编译器拿到带该注解的方法后，会立刻去父类（或接口）里找一个**方法名、参数类型、参数个数、参数顺序完全一致**的非-private / non-static 方法。漏掉泛型类型参数、把 int 写成 Integer、多一个 String 参数、少一个 boolean 标志位——全都会触发编译错误：method does not override or implement a method from a supertype。
这个错误不是警告，不能忽略，必须修复才能通过编译。它逼你面对真实签名，而不是靠“看起来差不多”蒙混过关。
泛型擦除后仍要保证桥接方法能对上
泛型方法重写最容易翻车：父类定义 public User load(User id)，丢掉了
- 手动补全泛型形参，写成
public T load(T id) - 用
javap -s查看父类方法的 descriptor，和子类生成的比对是否一致 - 在 IDEA 中开启设置：
Settings → Editor → General → Code Completion → Show the full signature for generic methods
private / static / final 方法加 @Override 必报错
这些方法从语言层面就不支持重写。@Override 一加，编译器立刻拒绝：
-
private void init()在父类中 → 子类里写@Override public void init()→ 报错 -
static String version()→ 加@Override→ 报错 -
final List→ 加config() @Override→ 报错
这不是 IDE 的提示问题，是 Java 语言规范强制拦截。如果你遇到这类报错，说明你根本没理解父类设计意图，别硬改签名，先确认是不是该换继承策略或用组合替代。
Spring 环境下容易误判“已覆盖”，其实代理没生效
在 Spring Boot 的 @Service 类中覆盖父类方法，@Override 编译通过 ≠ 运行时真调用到子类逻辑。常见陷阱：
- 父类和子类都加了
@Service，但注入的是父类类型 → 实际调用父类方法（代理对象没指向子类实例） - 父类方法有
@Transactional，子类覆盖后没加 → 事务切面不生效，数据库操作脱离事务控制 - 覆盖的是模板方法里的钩子（如
beforeSave()），但父类调用它用的是this.beforeSave()→ 即使子类重写了，也因 this 指向父类实例而调不到
真正验证是否生效，得看运行时行为：用 new Child().method() 测试没问题，不代表 Spring 容器里也走通。必须在实际 Bean 注入上下文中调试，比如打日志或断点进代理对象内部。
最常被忽略的一点：当你在实现接口时加 @Override，它校验的是接口定义；而在继承抽象类时加，它校验的是抽象类里声明的 abstract 或 default 方法——两者语义不同，但报错信息一模一样，容易查偏方向。
