Java注解是能被编译器、工具或运行时读取并触发行为的元数据，需配合处理器、反射或框架（如Spring、JUnit）才能生效；它不直接改变逻辑，但可替代XML配置、减少样板代码、统一处理横切关注点，也需权衡性能、可读性与调试难度。
Java 注解不是“写给人看的备注”，而是能被编译器、工具或运行时读取并触发行为的元数据。它本身不直接改变逻辑，但配合处理器（如 AnnotationProcessor）、反射（Class.getDeclaredAnnotations()）或框架（Spring、JUnit）才能真正起作用。
什么时候必须用注解：替代 XML 配置和减少样板代码
Spring 从 2.5 开始大力推动基于注解的配置，目的就是把原本分散在 XML 文件里的 bean 定义、事务边界、请求映射等，直接写在类或方法上。这不是炫技，是为了解决维护成本高、配置与代码脱节的问题。
-
@Component、@Service、@Repository替代<bean class="..."></bean>，让 Spring 扫描自动注册 -
@Transactional比手动写TransactionTemplate.execute()更简洁，且支持声明式回滚规则 -
@RequestMapping("/user")直接绑定 URL 和处理方法，不用再维护一个单独的路由表
什么时候该自己写注解：需要统一拦截/校验/日志的场景
当你发现多个方法都要做同一件事（比如记录操作日志、检查用户权限、验证参数非空），又不想每个地方都重复调用工具类，就该考虑自定义注解 + AOP 或反射处理。
- 定义注解时加
@Retention(RetentionPolicy.RUNTIME)，否则反射拿不到 - 加
@Target({ElementType.METHOD, ElementType.TYPE})明确可用位置，避免误用 - 运行时通过
method.getAnnotation(MyLog.class)获取，再结合ProceedingJoinPoint实现环绕逻辑 - 注意：不要在注解里存大对象或闭包，它只应是轻量元数据
哪些注解容易踩坑：@Override、@Deprecated、@SuppressWarnings
这三个是 JDK 自带的“基础款”，但用错会导致编译失败或掩盖真实问题。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
-
@Override写在实现接口方法上——Java 8 之前不支持，会报错；必须确保父类/接口中真有该签名方法 -
@Deprecated只是标记，不阻止调用；若想强制升级，得配合@Deprecated(since = "2.1")和文档说明 -
@SuppressWarnings("unchecked")别滥用，它跳过编译检查；先确认是不是真能保证类型安全，而不是为了消除警告而加 - IDE 可能对
@SuppressWarnings的值提示不全，建议用字符串字面量而非常量（如不用WARNINGS.UNCHECKED）
注解不是银弹：性能、可读性与调试难度的平衡
过度依赖注解会让代码“看不见逻辑”。比如一个方法被 @Cacheable、@Transactional、@Retryable 套了三层，实际执行顺序、异常传播路径、缓存 key 生成规则，全得查框架文档或源码。
- 运行时反射读取注解有开销，高频调用的方法慎用（如算法核心循环内）
- 自定义注解处理器（
AbstractProcessor）只能在编译期生效，无法处理运行时动态生成的类 - 单元测试中，若逻辑藏在注解背后，需用
Mockito.spy()或启动完整上下文（如@SpringBootTest），测试成本上升
真正难的不是写注解，而是判断哪部分逻辑适合抽成注解——它应该解决横切关注点，而不是把业务规则也塞进去。一个注解如果需要传 5 个参数、嵌套另一个注解、还得配外部配置文件，那大概率设计错了。
