@override报错是因为方法签名未严格匹配父类或接口：方法名、参数类型/顺序、返回类型（协变除外）、异常声明须一致；常见于参数类型不等价、访问权限降级、误覆写static方法或泛型擦除导致的签名不匹配。
为什么加了 @Override 编译器反而报错？
不是注解有问题，而是你写的“重写”根本没对上父类或接口的签名。Java 编译器用 @Override 做的是**严格契约校验**：方法名、参数类型、参数顺序、返回类型（协变除外）、异常声明，全得匹配。哪怕只是把 String 写成 Object 当参数，或者漏了个 throws IOException，编译就失败。
常见错误现象：Method does not override method from its superclass；或者 IDE 显示“Method never used”，其实是根本没成功重写，调用时走的是父类逻辑。
- 检查父类/接口里对应方法是不是
public—— 子类重写不能降级访问权限 - 确认参数类型是否完全一致，比如
List<string></string>和ArrayList<string></string>不等价 - 留意泛型擦除影响：接口中定义
<t> void process(T t)</t>，实现类不能写成void process(String s)，得保持类型变量
@Override 在接口默认方法和静态方法上的行为差异
Java 8+ 允许接口有 default 方法，但只有继承该接口的类才能用 @Override 去重写它；而接口里的 static 方法**不能被重写**，加 @Override 会直接编译失败 —— 它属于接口自身，不参与多态分派。
使用场景：当你在实现类里想定制某个默认行为（比如 Collection.sort() 的默认排序逻辑），必须显式加 @Override 才算真正覆盖。
- 实现类重写接口
default方法：必须加@Override，否则是新增方法，不是覆盖 - 子接口想“覆写”父接口的
default方法？不行，只能重新声明为default并提供新实现，此时也要加@Override - 别给
static方法加@Override—— 编译器会立刻拒绝，这不是疏忽，是语言设计如此
不加 @Override 看似能跑，但埋了什么雷？
最典型的问题是父类升级后方法签名变了，你的子类“看起来还在工作”，其实早就不走重写逻辑了。比如 JDK 把 toString() 的返回类型从 String 改成 CharSequence（现实中没改，仅作示意），没加 @Override 的子类不会报错，但运行时调用的仍是旧版父类实现。
另一个隐形成本是可读性下降：别人看代码时无法快速判断这个方法是“全新定义”还是“有意覆盖”，尤其在大型继承链中，容易误删或误改。
- IDE 通常默认高亮未加
@Override的疑似重写方法，这是提醒你确认意图 - 某些 Lint 工具（如 ErrorProne）会警告“Missing @Override”，把它当缺陷处理
- Android 开发中，
Activity生命周期方法如果漏掉@Override，可能因拼写错误（如onCreat()）导致回调静默失效，极难排查
Kotlin 和 Java 混合项目里 @Override 还需要手动加吗？
Kotlin 编译器默认要求重写必须显式用 override 关键字，所以 Java 侧调用 Kotlin 类时，只要 Kotlin 那边写了 override fun xxx()，Java 里加不加 @Override 都不影响编译；但建议仍加上 —— 因为 Java 代码可能被其他纯 Java 模块引用，且统一风格利于协作。
容易踩的坑在于：Kotlin 的 open 修饰符是显式的，父类函数不加 open 就不能被重写；而 Java 默认所有非 private/final 方法都可被重写。这种不对称容易让人误以为“Kotlin 类的方法天然可覆盖”。
- Kotlin 类被 Java 继承时，只有带
open的函数才允许 Java 用@Override重写 - Kotlin 调用 Java 类方法并重写，必须加
override，且 Java 端最好也配@Override，形成双向契约 - Gradle 构建时若启用
-Xjvm-default=all，Kotlin 生成的默认方法桥接代码可能让 Java 的@Override校验更敏感，需注意兼容性
最常被忽略的一点：重写构造器不存在，@Override 永远不能用在构造方法上；还有，Lambda 表达式或匿名内部类里重写方法，同样需要 @Override —— 它不是只属于“显式 class 定义”的语法糖。
