@override 和 @deprecated 是 java 中用于保障代码正确性与可维护性的编译期契约工具：前者强制校验方法重写合法性，后者标记弃用并触发警告，二者协同实现意图清晰、演进可控的协作开发。
@Override 和 @Deprecated 是 Java 中最常用、最基础的两个内置注解，它们不参与运行时逻辑，但对编译器行为有明确约束——这种约束直接影响代码正确性、可维护性和协作效率。
@Override：强制校验方法重写关系
该注解用于标记一个方法意在重写父类（或接口）中已声明的方法。它的核心作用不是“告诉编译器去重写”，而是“请编译器检查这个重写是否合法”。一旦添加，编译器会严格比对以下几点：
- 被标注方法必须确实存在于直接父类或实现的接口中（含继承链上的可见方法）
- 方法名、参数列表（类型、数量、顺序）必须完全一致
- 返回类型需满足协变规则（子类型可作为返回值，如 Object → String 允许，反之不行）
- 访问修饰符不能比父类方法更严格（如父类是 protected，子类不能用 private）
常见误用场景：拼错方法名（如 toString() 写成 toSting()），或参数类型写错（List
@Deprecated：标记弃用并触发编译警告
该注解表示被标注的类、方法、字段等**不推荐继续使用**，通常因存在更优替代、存在安全隐患或设计已被淘汰。它本身不改变程序行为，但编译器会在调用处发出警告（warning），提醒开发者注意迁移。
- 从 Java 9 开始，建议配合 @Deprecated(since = "x.y") 指明弃用版本，并在 Javadoc 中说明替代方案（如 “Use newMethod() instead”）
- 仅加注解不会阻止编译通过，也不会阻止运行；若需强约束，可搭配 @SuppressWarnings("deprecation") 局部抑制，或通过构建工具（如 Maven）配置为“将弃用警告转为错误”
- 注意：JDK 自身大量使用该注解（如 Thread.stop()、Date(String)），阅读源码或 IDE 提示时需重视其含义
二者的关键区别与协同使用
@Override 是编译期“硬约束”：不满足即编译失败；而 @Deprecated 是编译期“软提示”：仅警告，仍可运行。两者常出现在同一上下文中：
- 当某个旧方法被标记为 @Deprecated，新版本类中又提供了一个功能等价但签名不同的方法，子类重写时应使用 @Override 标注新方法，同时在旧方法上保留 @Deprecated
- 切勿在未真正重写的方法上滥用 @Override，也勿对仍在主力使用的 API 轻率添加 @Deprecated —— 它代表一种契约承诺，影响下游所有调用方
小结：它们不是语法糖，而是契约工具
这两个注解的价值不在“让代码跑起来”，而在“让代码意图清晰、演进可控、协作顺畅”。IDE 会高亮、编译器会校验、团队成员能快速理解设计意图。忽略它们，可能让重构变成灾难，让维护变成猜谜。
