@Override是编译期静态校验工具，编译器通过比对方法名、参数列表、返回类型兼容性及访问权限等要素，确保子类方法真正重写父类方法，防止伪重写导致的隐蔽bug。
Java 子类复写父类方法时，通过 @Override 注解实现语法检查——它不是运行时机制，而是编译器在编译阶段自动比对方法签名的静态校验工具。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
为什么加 @Override 就能检查语法？
编译器看到 @Override 后，会严格核对子类方法是否满足重写前提： - 方法名完全一致（大小写敏感） - 参数列表完全相同（类型、个数、顺序，含泛型擦除后的原始类型） - 返回类型兼容（基本类型和 void 必须相同；引用类型允许协变，如父类返回 List，子类可返回 ArrayList） - 父类方法必须是 public/protected、非 static、非 final、非 private
不加注解会发生什么？
编译器不做任何校验，即使出现以下情况也能通过编译，但实际并未重写： - 方法名拼错（如 toString 写成 toStirng） - 参数类型不匹配（如父类接收 String，子类写了 Object） - 父类方法已被删除或改名，子类方法变成孤立存在 结果是：多态调用仍执行父类逻辑，bug 隐蔽且难定位。
怎么用才真正起作用？
正确做法很简单，但必须坚持：
- 所有明确意图复写父类方法的地方，都加上 @Override
- IDE 自动生成重写方法时默认带该注解，不要手动删掉
- 编译报错时，顺着提示排查，而不是绕过注解
例如父类有：
public void save(User u) { ... }
子类必须写：
@Override
public void save(User u) { ... }
若误写为 save(Object o)，编译器立刻报错：“method does not override”。
哪些情况加了也会失败？
这是好事——说明复写本身不合法，@Override 帮你提前暴露问题： - 父类方法是 private 或 static → 无法被重写 - 子类访问修饰符更严格（如父类 public，子类写成 protected） - 抛出新的受检异常（如父类没声明异常，子类却 throws IOException） 这些都不是语法书写错误，而是违反 Java 重写规则的根本性问题。
