注解在字节码层面“存在”或“可用”的关键在于@retention策略：source仅限编译期，class保留字节码但反射不可见，runtime则支持运行时反射访问，三者分别对应不同使用场景与性能开销。
要让注解在字节码层面“存在”或“可用”，关键不在源码写法，而在@Retention策略的选择。它不是可有可无的配置项，而是直接决定注解能否被javap看见、能否被反射读取、甚至影响JVM加载行为的底层开关。
SOURCE策略：编译即删，字节码里彻底清零
这类注解只对编译器和IDE有意义，javac处理完就丢弃，不生成任何字节码痕迹：
-
javap -v 查不到任何线索：搜索
RuntimeVisibleAnnotations或注解全限定名，结果为空 -
反射永远返回 null：哪怕方法上写了
@MyAnno，method.getAnnotation(MyAnno.class)也恒为null - 零体积、零开销：不占.class大小，不拖慢类加载，适合纯提示型场景
典型用途：@Override、@SuppressWarnings、Lint自定义规则标记、@ApiStatus等仅用于静态检查或文档生成的注解。
CLASS策略：字节码可见，但JVM运行时屏蔽
注解签名会写进class文件的RuntimeVisibleAnnotations属性（JVM规范统一用此名），但JVM加载时不暴露给反射API：
-
javap -v 能搜到：可见类似
#12 = Utf8 Lcom/example/MyAnno;的常量池项，以及对应属性表内容 -
反射调用一律失败：
isAnnotationPresent()返回false，getDeclaredAnnotations()不含该注解 - 构建期友好，运行期干净：Dagger、Lombok、ASM、Android APT等工具依赖此阶段读取元数据，无需污染运行时内存
这是默认策略，适合“编译后即用、运行中即弃”的协作流程，比RUNTIME轻量，又比SOURCE多一层中间态。
RUNTIME策略：字节码保留 + JVM元空间加载 + 反射开放
这是唯一能让注解贯穿到运行时的策略。它不仅写入字节码，还强制JVM将注解元数据加载进元空间（Metaspace），供反射API实时访问：
-
javap -v 显示完整结构：包含
RuntimeVisibleAnnotations属性及嵌套值（如value = "test"） -
反射调用稳定返回实例：
getAnnotation()能拿到真实对象，属性方法可正常调用 - 性能成本真实可测：每个RUNTIME注解增加数十至上百字节class体积；百万级类规模下，类加载延迟与GC压力显著上升；高频反射扫描比CLASS策略慢3–5倍
必须用的场景：Spring @Autowired、JUnit @Test、自定义AOP切面（如@Trace）、权限校验（@RequireRole）、事务控制（@Transactional）——所有依赖运行时动态行为注入的功能。
验证必须两步走：字节码 + 反射双确认
单看javap只能确认“是否写入”，单跑反射只能确认“是否可用”。真正生效需两者同时满足：
-
第一步：执行
javap -v TargetClass.class | grep -A 5 -B 5 "MyAnno"，确认注解签名和RuntimeVisibleAnnotations存在 -
第二步：写最小测试用例，调用
method.getAnnotation(MyAnno.class)，观察是否返回非null实例 - 缺一不可：javap有但反射空 → 策略设错（比如用了CLASS）；反射有但javap无 → 注解根本没编译进class（比如拼写错误或未正确应用）
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
