根本原因是运行时“看到的类”与预期不一致，需直击类加载、签名匹配、模块边界三层问题：验证类来源、比对字节码签名、检查模块opens配置。
Java 反射异常在版本升级后高频出现，根本原因不是代码写错了，而是运行时“看到的类”和你预期的不一致。排查要跳过“是不是方法名打错了”这种表层思路，直击类加载、签名匹配、模块边界这三层本质问题。
确认异常类型，区分处理路径
不同反射异常对应不同根因，升级场景下需优先识别：
- NoSuchMethodException：编译期存在、运行期找不到——大概率是方法被移除、重命名，或签名因泛型擦除/基本类型与包装类差异而失配
- NoSuchFieldException：字段被删、改名、设为 private 且未用 getDeclaredField + setAccessible
- IllegalAccessException / InaccessibleObjectException：JDK 9+ 模块强封装生效，反射访问 JDK 内部类（如 java.lang.reflect.* 或 sun.misc.*）或未 opens 的包
- InvocationTargetException：反射调用成功，但目标方法内部抛异常——此时要看 getCause()，它才是真凶（比如 POI 升级后构造函数参数变了）
比对运行时实际加载的类与源码预期
IDE 里能跳转、编译能过，不代表运行时加载的是同一个类。必须验证：
- 打印关键类的来源：System.out.println(YourClass.class.getProtectionDomain().getCodeSource())，确认 jar 路径和版本号是否符合升级预期
- 用 javap -s -p YourClass 查看字节码中的方法签名、字段类型、serialVersionUID，和旧版本逐项比对
- 启动加 JVM 参数 -Xlog:class+load=debug（JDK 17+），或用 Arthas sc -d com.xxx.YourClass 查加载器和 jar 路径，避免“本地跑得通、打包就崩”
检查方法/字段签名是否真正匹配
升级常伴随 API 改动，仅看方法名远远不够：
- 基本类型和包装类不等价：int.class ≠ Integer.class，JDK 8 传 Integer 可能自动拆箱，JDK 17+ 反射严格校验，必须一致
- 泛型已擦除：声明 void process(List
) ，反射必须传 List.class，不能传 ArrayList.class 或 Object.class - 数组写法敏感：String[].class 和 String.class 是完全不同的类型
- varargs 方法：声明 void log(String... msgs)，反射调用时参数类型数组应为 new Class[]{String[].class}
验证模块化与反射权限配置
JDK 9+ 升级后，--illegal-access=deny 已成默认。若反射涉及 JDK 内部类或第三方库私有成员：
- 查报错栈中被访问的类全名（如 java.lang.System::logger），按格式加启动参数：--add-opens java.base/java.lang=ALL-UNNAMED
- 若用 Spring Boot，可在 spring-boot-maven-plugin 配置
注入；容器部署则改启动脚本 - 避免用 Class.forName("xxx")，改用 Thread.currentThread().getContextClassLoader().loadClass("xxx")，确保加载器上下文一致
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
