反射失效的根本原因是混淆器在压缩阶段直接移除反射目标而非仅重命名；解决关键是通过精准-keep规则保留类、方法、字段及signature等元数据，并验证映射与字节码。
反射失效的根本原因，是混淆工具在压缩（Shrink）阶段把本该保留的类、方法或字段直接移除了，而不是单纯重命名。只要类结构不存在了，Class.forName()、getDeclaredMethod()这类调用必然抛出 ClassNotFoundException 或 NoSuchMethodError。解决重点不在“绕过混淆”，而在于让混淆器明确知道：这些元素虽未被静态调用，但必须保留。
明确标识需保留的反射目标
不能依赖模糊规则（如 -keep class **.model.**），要精准锚定实际被反射调用的类与成员：
- 逐个确认反射入口点：比如
Class.forName("com.example.api.ConfigLoader")中的全限定名，或obj.getClass().getMethod("parseData")中的方法签名 - 对每个目标类，添加带成员约束的
-keep规则，例如：
-keep class com.example.api.ConfigLoader { *; }（保留全部）或更细粒度的
-keep class com.example.api.ConfigLoader { public(...); public java.lang.String getData(); } - 若反射访问私有字段，需额外保留
setAccessible(true)所需的字段声明，不能只留 getter/setter
强制保留泛型与注解元数据
泛型类型信息（Signature 属性）和运行时注解（@SerializedName、@Inject 等）一旦被混淆器擦除，getGenericSuperclass() 或 getAnnotation() 就会失败，甚至触发 GenericSignatureFormatError：
- 在 ProGuard/R8 配置中必须加入：
-keepattributes Signature,RuntimeVisibleAnnotations,RuntimeVisibleTypeAnnotations - Kotlin 项目还需追加：
-keepattributes KotlinMetadata,AnnotationDefault - 避免使用
-dontusemixedcaseclassnames，它可能破坏 JVM 内部泛型结构的兼容性
处理动态加载与间接引用场景
有些类不是通过硬编码字符串反射，而是由配置文件、JSON 字段、服务发现机制等间接决定——混淆器完全无法静态识别：
- 对所有可能被字符串加载的类路径，统一放入白名单，例如：
-keep class com.example.plugin.** { *; } - 若使用
DexClassLoader加载插件 APK，确保插件自身的混淆规则独立且完整，主工程不负责其保留逻辑 - 对 Lambda 表达式生成的合成类（如
$Lambda$123），可添加：
-keep class **$$Lambda$* { *; }
验证与调试的关键动作
仅写规则不够，必须验证混淆后的真实字节码是否符合预期：
- 启用
-printmapping mapping.txt和-verbose，构建后检查目标类是否出现在 mapping 文件中，且未被标记为 “==>”（即未被重命名或移除） - 用
javap -v反编译 release 版本的 class 文件，确认目标类存在、字段/方法签名完整、Signature属性未为空 - 编写最小化测试用例，在 release 包中直接运行反射逻辑，捕获异常并定位到具体哪一行调用失败
