nosuchmethoderror 是运行时链接错误，因类版本不匹配导致方法符号引用解析失败；反射调用抛 nosuchmethodexception 是正常流程控制，可捕获处理。
直接调用时出现 NoSuchMethodError，说明类文件不匹配
这通常不是代码写错了，而是运行时加载的类版本和编译时依赖的版本不一致。比如你用 JDK 17 编译，但运行在 JDK 8 上，或者 Maven 引入了两个不同版本的同一 jar，老版本里没有你调用的新方法。
常见错误现象：NoSuchMethodError: com.example.Utils.doWork(Ljava/lang/String;)V，但你明明写了这个方法、IDE 也不报错。
- 检查
mvn dependency:tree -Dverbose，确认实际打进包的是哪个版本 - 用
javap -cp your.jar com.example.Utils看字节码里是否存在该方法签名 - 注意：
NoSuchMethodError是Error，继承自LinkageError，不能被常规catch (Exception e)捕获
反射调用时抛 NoSuchMethodException，是运行期查不到方法
这是正常流程控制的一部分，不是环境问题。只要 Class.getDeclaredMethod() 或 getMethod() 找不到匹配的方法签名，就立刻抛这个 Exception —— 它属于 ReflectiveOperationException，可捕获可处理。
使用场景：动态调用插件方法、测试框架查找 @Test 方法、JSON 反序列化时找 setter。
立即学习“Java免费学习笔记（深入）”；
-
getMethod()只查 public 方法（含父类），getDeclaredMethod()查本类所有（含 private），但不递归父类 - 参数类型必须精确匹配：传
String.class找不到接受CharSequence的方法；自动装箱（intvsInteger）也不算匹配 - 泛型擦除后的方法签名才是真实匹配依据，别被 IDE 的提示骗了
NoSuchMethodError 不可能在反射中出现，除非反射触发了后续直接调用
反射本身只负责“找方法”，找到后用 method.invoke() 才真正执行。如果此时目标方法内部又调用了某个已删/改名的外部方法，那个外部调用才可能触发 NoSuchMethodError。
也就是说：反射安全边界只到“获取 Method 对象”为止；invoke() 是另一层风险。
- 不要假设
getDeclaredMethod()成功 = 后续一定能跑通 - 如果反射调用后立即崩出
NoSuchMethodError，问题不在反射逻辑，而在被调方法体内部的硬编码调用 - 热部署或模块化（JPMS）环境下，类加载器隔离可能导致看似同名类实为不同实例，也会引发此类问题
为什么编译期没报错，运行却崩？关键在「链接阶段」
Java 分三步：编译 → 加载 → 链接（验证、准备、解析）。NoSuchMethodError 发生在解析阶段——JVM 尝试把符号引用转为直接引用时失败。而编译器只校验源码可见的 classpath，不校验运行时实际加载的字节码。
这就是为什么改完依赖、升级 SDK、甚至只是换个 classloader，都可能让原来好好的代码突然挂掉。
- CI 环境用的 JDK 版本要和生产严格一致
- 避免在接口默认方法里调用尚未稳定发布的其他 API
- 对第三方库的关键方法调用，加一层存在性检查（如
Class.getMethod(...)+try/invoke），比硬编码更健壮
