选对@Retention的核心是按需选用：SOURCE用于编译期检查与代码生成，CLASS用于构建期字节码处理，RUNTIME仅当运行时反射必需——避免资源浪费与性能损耗。
选对 @Retention 不是“让注解更强大”，而是让注解刚好够用——不浪费资源，也不掉链子。
谁需要读它？先锁定使用方
别猜，直接问：哪个环节依赖这个注解的信息？答案决定策略。
- 编译器或 IDE 要检查、提示、生成代码 → 选 SOURCE（如
@Override、Lombok 的@Getter） - 构建工具要扫描字节码、插桩、校验、生成辅助类 → 选 CLASS（如 ASM 分析权限注解、APT 生成 DAO）
- 运行时逻辑要动态判断、拦截、序列化、注入 → 必须选 RUNTIME（如 Spring 的
@Component、自定义@RequiresRole）
RUNTIME 用得最多，也最容易拖慢系统
它确实灵活，但代价真实可见：
- 每个 RUNTIME 注解都会增大
.class文件体积，微服务打包多时会累积放大 - 类加载阶段要解析并缓存元数据，拖慢启动速度，增加元空间压力
-
method.getAnnotation()比普通字段访问慢 10–100 倍，高频调用必须缓存结果 - 注解内容（比如角色名、校验规则）可能被反射读取，构成信息泄露风险
CLASS 是默认值，但常被误用
没写 @Retention 就是 CLASS，但它不是“折中方案”——它是专为构建期工具设计的。
立即学习“Java免费学习笔记（深入）”；
- 它写进字节码，但 JVM 加载时不加载，反射 API 查不到（
getAnnotation()返回null） - 适合做编译后处理：自动加日志埋点、静态安全扫描、覆盖率注入
- 不能用于 Spring AOP 这类基于代理+反射的场景——换框架就失效
SOURCE 是性能最优解，却被低估
零运行时成本，纯编译期服务，适合绝大多数辅助性标注。
- 只存在于
.java文件，javac 编译完就清空，.class里完全找不到 - 适用于空值检查（
@NonNull）、线程安全标记、IDE 重构支持、Protocol Buffer 代码生成 - 如果注解只是用来生成 getter/setter 或模板日志，却设成 RUNTIME，等于主动引入技术债
