Java注解本身不执行逻辑，其“生效”依赖@Retention策略及配套处理机制：SOURCE级由编译器检查，CLASS级供字节码工具织入，RUNTIME级通过反射读取；Spring等框架需扫描与代理等显式支撑。
注解本身不执行任何逻辑
Java 注解（@interface）只是元数据标记，编译后默认不产生任何运行时行为。比如 @Override、@Deprecated 这类内置注解，靠的是 JVM 或编译器硬编码识别；而自定义注解如 @Log、@Route，必须配合额外机制才能“生效”。
关键判断点：如果你写了注解但没看到效果，大概率是漏掉了处理环节——不是注解写错了，而是没人读它。
三种主要生效路径：编译期、运行时、APT
注解的“生效”取决于它的 @Retention 策略和配套处理方式：
-
源码级（
RetentionPolicy.SOURCE）：仅保留在 .java 文件中，如@Override，由javac在编译时检查，编译完就丢弃 -
类文件级（
RetentionPolicy.CLASS）：写入 .class 但不加载进 JVM，某些字节码工具（如 AspectJ、Byte Buddy）可在类加载前织入逻辑 -
运行时（
RetentionPolicy.RUNTIME）：通过Class.getDeclaredAnnotations()或Method.getAnnotation()反射读取，Spring 的@Autowired就走这条路
注意：RetentionPolicy.CLASS 注解无法用反射获取，强行调用 getAnnotation() 返回 null，这是常见误判点。
立即学习“Java免费学习笔记（深入）”；
Spring 中的注解为何“自动生效”
Spring 并不是魔法，它的注解（如 @Service、@Transactional）依赖两层支撑：
-
组件扫描：配置了
@ComponentScan后，Spring 在启动时用ClassPathBeanDefinitionScanner扫描 classpath，通过反射检查类是否含@Component等注解，匹配后注册为 Bean -
AOP 代理：
@Transactional这类行为型注解，实际由TransactionInterceptor拦截方法调用，该拦截器绑定在代理对象上——没有启用@EnableAspectJAutoProxy或对应配置，注解就只是个标记
换句话说：Spring 容器本身不“解析”注解，它只是按约定读取、按规则触发。你手动 new 一个加了 @Service 的类，@PostConstruct 不会执行，@Value 也不会注入。
手写注解处理器的关键陷阱
如果想自己实现类似功能，别直接从反射开始——先确认三件事：
- 注解的
@Target是否覆盖你的目标元素（比如对字段用了只允许方法的注解，反射根本拿不到） - 运行时注解必须确保类已被加载且未被类加载器跳过（如模块系统下
requires缺失会导致ClassNotFoundException） - 反射读取性能敏感：频繁调用
getDeclaredAnnotations()会触发多次类加载和解析，生产环境建议缓存结果，或改用 ASM/Byte Buddy 在类加载阶段处理
最常被忽略的一点：注解属性值如果是数组或嵌套注解，默认不能为 null，未显式赋值时取默认值（如 String[] value() default {}），空数组 ≠ null，判空逻辑写错就会漏处理。
