代码混淆若未保留注解结构，会导致反射读取注解失败：注解类被重命名、被注解成员被删改、注解内方法或常量被混淆，均使getannotation()返回null或抛异常；需配置-keep规则保护注解及关联元素。
代码混淆（如 ProGuard、R8、Jscrambler 等）在压缩、重命名类、方法、字段时，若未合理保留注解相关结构，会直接导致运行时通过反射读取注解失败。
混淆会破坏注解存在的前提条件
Java 注解默认具有 RetentionPolicy.CLASS 或 RetentionPolicy.RUNTIME。只有后者才能被反射读取。但即使声明为 @Retention(RetentionPolicy.RUNTIME)，以下情况仍会导致反射失效：
- 注解类本身被混淆重命名（如
@ApiModel变成a），反射调用getAnnotation(ApiModel.class)因类名不匹配而返回null - 被注解的目标元素（如字段、方法）被重命名或内联，导致原本的反射路径（如
clazz.getDeclaredField("userName")）找不到目标，进而无法调用getAnnotation() - 注解中引用的常量、枚举或嵌套类被移除或混淆，造成注解字节码结构损坏，JVM 解析失败
常见混淆工具的默认行为加剧风险
R8（Android 默认）和 ProGuard 在启用优化（-optimizationpasses）、压缩（-shrink）或重命名（-obfuscation）时，默认不会特殊保护注解——除非显式配置：
-
-keep @interface *：保留所有注解接口定义（必要但不充分） -
-keepattributes Signature,RuntimeVisibleAnnotations,RuntimeInvisibleAnnotations：确保注解属性保留在 class 文件中 -
-keepclassmembers class * { @your.package.annotation.* *; }：保留被指定注解标记的成员（防止字段/方法被删或重命名） - 对使用反射访问的注解类，还需
-keep class your.package.annotation.** { *; }防止其内部字段（如value()）被重命名
反射读取注解的典型失效场景示例
假设存在如下代码：
@Data
@TableName("user_info")
public class User {
@TableField("nick_name")
private String nickName;
}
若未配置混淆规则：
-
@TableName类被重命名为a→User.class.getAnnotation(TableName.class)返回null -
nickName字段被重命名为a→User.class.getDeclaredField("nickName")抛出NoSuchFieldException，后续getAnnotation(TableField.class)无从执行 -
TableField.value()方法被重命名 → 即使拿到注解实例，调用annotation.value()也会抛出NoSuchMethodException
验证与调试建议
混淆后检查注解是否可用，不能仅依赖编译期检查，需结合实际运行时验证：
- 反编译混淆后的 APK 或 JAR（如用
javap -v ClassName.class），确认RuntimeVisibleAnnotations属性是否存在且内容完整 - 在关键反射逻辑处添加日志，打印
getAnnotations()结果长度、逐个输出注解类名，快速定位缺失点 - 对框架级注解（如 Spring、MyBatis、Lombok），优先查阅对应文档的混淆适配说明；例如 MyBatis-Plus 明确要求保留
@TableName等注解及value()方法 - 单元测试应在混淆后环境中运行（如 Android 的
testProguardDebug），而非仅本地 JVM
