内置注解是团队协作的通用语言：@Override确保方法重写正确性，@Deprecated标记废弃路径并指引替代方案，@SuppressWarnings精准抑制警告并需附说明，@FunctionalInterface锁定函数式接口契约。
内置注解不是装饰代码的“贴纸”，而是团队成员之间无需开口就能读懂彼此意图的通用语言。它把隐含的约定、设计约束和协作意图，直接写进代码结构里，让阅读者一眼明白“这里为什么这么写”。
用 @Override 明确接口契约，避免重写歧义
子类方法是否真在覆盖父类行为？靠人眼比对容易出错，尤其在大型继承链中。加上 @Override 后，编译器自动校验签名一致性，一旦父类方法名变更或参数调整，错误立刻暴露。
- 新成员接手时，看到 @Override 就知道这个方法有明确的上层定义，不必翻查父类源码确认是否存在
- 重构父类时，所有带 @Override 的子类方法会同步报错，强制开发者检查影响范围
- 不加该注解的“伪重写”可能静默运行，但实际调用的是父类方法，埋下逻辑缺陷
用 @Deprecated 标记演进路径，减少误用与沟通成本
功能迭代中旧方法不能立刻删除，但必须让所有人知道“别再用了”。@Deprecated 不仅触发 IDE 删除线提示，更应配合 JavaDoc 说明替代方案。
- 在注释中写明“请改用 UserService.findUserById(Long)”，比口头通知或群消息更持久、可追溯
- CI 流程可配置扫描 @Deprecated 使用频次，识别高风险残留调用
- 新人看到被划掉的方法，自然会点开查看推荐用法，减少重复提问
用 @SuppressWarnings 精准控制警告，聚焦真正问题
泛型强转、资源未关闭等警告若泛滥，反而掩盖关键风险。@SuppressWarnings 应限定作用域和警告类型，比如只抑制特定行的 "unchecked"，而非整个方法。
- 写成 @SuppressWarnings("unchecked") 比 @SuppressWarnings("all") 更清晰，表明开发者已评估过该转换的安全性
- 团队可约定：所有 @SuppressWarnings 必须附带单行注释，说明原因（如“此处由上游保证类型安全”）
- 静态检查工具能识别无注释的抑制项，提醒补全说明，避免随意屏蔽
用 @FunctionalInterface 锁定函数式契约，统一回调理解
当一个接口被标记为 @FunctionalInterface，团队立刻达成共识：它只允许一个抽象方法，适合用 Lambda 表达式实现。这消除了“这个接口能不能用箭头函数”的反复确认。
- 新增方法时，编译器强制报错，防止无意破坏函数式语义
- 文档和 API 设计可默认按单方法契约描述，无需额外说明“仅支持一种行为”
- 测试用例可围绕 Lambda 调用方式编写，提升覆盖率的一致性
