反射时抛出 NoSuchFieldException 的最常见原因
90% 的 NoSuchFieldException 都是因为字段名拼写错误，尤其是大小写不一致——Java 字段名严格区分大小写，而开发者常凭印象写成 userName 却实际定义为 username 或 USERNAME。
反射查字段本质是字符串匹配，不会做任何“近似查找”或“驼峰容错”。哪怕只错一个字母或大小写，Class.getDeclaredField("<code>xxx") 就直接炸。
- 检查目标类的源码或反编译结果，确认字段声明的**原始拼写和大小写**（注意：IDE 自动补全有时会误导）
- 用
clazz.getDeclaredFields()打印所有字段名，比对真实存在的名字，别靠记忆 - 如果字段是继承来的，
getDeclaredField查不到——它只查本类声明的字段，得用getField（但仅限 public）或递归遍历父类
getDeclaredField 和 getField 的行为差异
这两个方法查字段的范围和权限完全不同，选错就必然抛 NoSuchFieldException。
-
getDeclaredField：只返回本类中声明的字段（含 private、protected、package-private），不管是否 public，但**不包括父类字段** -
getField：只返回本类及父类中 **public 字段**（包括从 Object 继承的 public 字段），private 和 protected 一律忽略 - 若字段在父类且为 private，两个方法都查不到——必须用
getDeclaredField在父类 Class 上调用
示例：子类 User 继承 BaseEntity，其中 id 是 BaseEntity 的 private 字段：
立即学习“Java免费学习笔记（深入）”；
BaseEntity.class.getDeclaredField("id"); // ✅ 正确
User.class.getDeclaredField("id"); // ❌ NoSuchFieldException
User.class.getField("id"); // ❌ 同样炸，因为 id 不是 public混淆、Lombok、Kotlin 编译后字段名变形问题
运行时字段名可能和源码不一致，尤其在用了代码混淆、Lombok 或 Kotlin 的场景下。
- Lombok 的
@Data生成的字段名就是源码写的那个，但 getter/setter 名称会变（如username→getUsername()），不影响字段反射；但若用了@FieldNameConstants或自定义@Getter(value = FieldName.XXX)，需确认生成逻辑 - Kotlin 编译后，
val name: String默认生成 private 字段name+ public getter，但若加了@JvmField，字段才真正 public 可见；没加的话，getDeclaredField("name")仍能查到，但它是 private 字段，需setAccessible(true) - ProGuard/R8 混淆后，字段名大概率被重命名（如变成
a、b），此时用源码名反射必失败；必须保留字段名：在 proguard-rules.pro 中加-keepclassmembers class * { *** fieldName; }
调试时快速验证字段是否存在
别靠猜，用几行代码当场验证字段可访问性：
- 先用
clazz.getDeclaredFields()列出所有字段名，确认目标字段是否在其中（注意大小写） - 再对匹配上的字段调用
field.getModifiers()看是否为 private，如果是，后续操作必须field.setAccessible(true) - 如果字段带泛型或注解，
getDeclaredField不受影响；但若字段是枚举常量或静态内部类实例，它不属于“字段”，而是java.lang.reflect.Field的特殊 case，不能用此方法获取
最简验证代码：
for (Field f : clazz.getDeclaredFields()) {
System.out.println("field: " + f.getName() + ", modifiers=" + f.getModifiers());
}字段名大小写是反射里最基础也最容易翻车的点，但更隐蔽的是字段来源（本类/父类）、可见性（private/public）、以及编译期改名（Lombok/Kotlin/混淆）这三层干扰。漏掉任意一层，NoSuchFieldException 就照炸不误。
