@retention决定注解必须存活到的阶段：source仅存于.java文件，编译即丢；class写入.class但运行时不可反射获取；runtime驻留方法区，支持反射读取，适用于spring、junit等框架。
Java 中的 @Retention 不是“要不要存注解”，而是明确告诉 JVM 和编译器：这个注解信息，**必须活到哪个阶段才允许被丢弃**。它不控制“怎么存”，但直接决定“在哪还能取到”——SOURCE 阶段取不到字节码里的东西，RUNTIME 阶段取不到 SOURCE 级注解，中间没有模糊地带。
注解到底存在哪？分三步看清楚
注解的物理存在位置，和 @Retention 的取值严格对应：
- SOURCE：只存在于 .java 文件中；javac 一过，彻底清空；.class 文件里完全找不到，反射当然读不到；适合编译器检查（如 @Override）或 IDE 提示。
- CLASS（默认）：写进了 .class 字节码的 RuntimeVisibleAnnotations 或 RuntimeInvisibleAnnotations 属性里；但 JVM 类加载时不会将其解析进运行时内存；ASM、Javassist 等工具可在加载前读取，反射 API 却查无此注解。
- RUNTIME：不仅写入 .class，还在类加载阶段被 JVM 解析并驻留在方法区（元空间）；此时 Class.getAnnotation()、Method.getAnnotation() 才能真正返回实例；Spring、JUnit、Jackson 全依赖这一层。
为什么 RUNTIME 不是默认？真实成本在这里
选 RUNTIME 不是“更高级”，而是承担了可测量的运行时开销：
- 每个 RUNTIME 注解都会增加 .class 文件体积（哪怕几十字节），在微服务大量 jar 包场景下会累积放大；
- JVM 加载类时需解析并缓存更多元数据，类加载变慢，元空间占用上升；
- 注解内容（比如校验规则、权限标识）暴露在运行时，可能被恶意反射读取，构成封装泄露风险。
怎么配才不踩坑？关键看“谁在什么时候读”
别凭感觉选，直接按使用方锁定策略：
- 编译器插件、IDE、lombok 处理器 → 用 SOURCE；
- 构建期字节码改写（如自动加监控埋点）→ 用 CLASS；
- 运行时动态行为（权限拦截、JSON 序列化、DI 注入）→ 必须 RUNTIME；
- 不确定？先从 SOURCE 或 CLASS 开始，等真需要反射再升级；避免“一步到位”式滥用。
一个典型误配案例
你写了 @Loggable 用于 AOP 日志，却配成 @Retention(CLASS)。AspectJ 编译期织入没问题，但如果换用 Spring AOP（基于代理 + 运行时反射判断），就会发现 method.isAnnotationPresent(Loggable.class) 永远返回 false——因为 Spring 在运行时根本看不到这个注解。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
