根本原因是混淆导致字段名被重命名或删除，使getDeclaredField("xxx")抛NoSuchFieldException；需用-keep规则保护字段，如-keepclassmembers class com.yourpackage.model.User { ; }，并验证mapping.txt和字节码。

混淆后通过反射找不到 Field，根本原因不是反射写错了，而是字段名在混淆过程中被重命名或删除了。只要字段没被保留，getDeclaredField("xxx") 就必然抛 NoSuchFieldException——这不是运行时权限或类加载问题，而是编译期结构已丢失。

哪些 Field 会被混淆掉？

ProGuard/R8 默认会对所有非公开、无直接引用的字段进行重命名或移除。尤其以下情况高危：

• private 字段（如 private String userName;）——最常被重命名为 a、b
• 仅被反射调用、无直接代码引用的字段（混淆器识别为“无用”）
• 注解标记的字段（如 @TableField("nick_name")），若注解类或目标字段未保留，整个链路断裂
• R 文件中的资源字段（如 R.drawable.smile），混淆后 smile 变成 a，getDeclaredField("smile") 必然失败

必须加的 -keep 规则

不能只写类名，要明确保护字段结构。常用且有效的写法：

• 保护整个类及其所有成员：-keep class com.yourpackage.model.User { *; }
• 只保字段不保方法（更精细）：-keepclassmembers class com.yourpackage.model.User { ; }
• 保护 R 文件所有内部类（关键！）：-keep class **.R$* { *; }
• 保护特定注解及其目标字段：-keep @interface com.baomidou.mybatisplus.annotation.TableField
-keepclassmembers @com.baomidou.mybatisplus.annotation.TableField class * { ; }

验证是否生效的实操方式

别只信配置写了，要看字节码是否真没变：

• 反编译 APK 或 JAR，用 javap -v YourClass.class 查看字段签名，确认字段名仍是原始名称（如 userName），而非 a、b
• 检查 mapping.txt：如果字段在映射文件中被重命名了，说明规则没生效或写错了包路径
• 在反射调用前加日志：Log.d("REF", Arrays.toString(clazz.getDeclaredFields()));，直接看运行时有哪些字段名

容易忽略但致命的细节

很多问题不是规则没写，而是写得不完整或位置不对：

• 使用通配符 ** 时注意路径是否包含子包，com.example.* 不匹配 com.example.entity.User，要用 com.example.**
• 第三方库自带注解（如 Gson 的 @SerializedName）也需单独保留：-keep @interface com.google.gson.annotations.SerializedName
• 启用 -keepattributes Signature，否则泛型字段（如 List items）可能因签名丢失导致反射获取类型异常
• debug 模式下不要开混淆——调试时字段名被改，断点进不去、变量看不到，排查成本翻倍