NoSuchMethodError 是运行时错误，因JVM仅在运行时校验方法签名是否存在，编译期不检查；常见于类路径污染导致加载了删改方法的旧版jar。
为什么 NoSuchMethodError 不是编译报错，运行才崩？
因为 JVM 在类加载时只校验方法签名是否存在，不校验它是否来自你“以为”的那个版本。编译期用的是 A 版本的 jar（含 doWork(String)），但运行时 classpath 里混进了 B 版本的 jar（删掉了这个方法或改了参数），JVM 找不到符号就直接抛 NoSuchMethodError——它不关心你编译时对不对，只认运行时实际加载的字节码。
常见错误现象：java.lang.NoSuchMethodError: com.example.Util.doWork(Ljava/lang/String;)V，但 IDE 里 Ctrl+Click 能跳转、mvn compile 没报错。
- 不是代码写错了，是「类路径污染」了
- 不是
NoClassDefFoundError，说明类加载成功了，只是方法没了 - Maven 多模块项目中尤其高发：父模块依赖旧版，子模块升级了但没强制统一
用 mvn dependency:tree 定位冲突源头
别猜，直接看 Maven 实际解析出的依赖树。重点不是“有没有”，而是“谁赢了”——Maven 默认按「最短路径优先」和「声明顺序」决定最终选用哪个版本。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 加
-Dverbose参数：mvn dependency:tree -Dverbose | grep Util，能看到被省略（omitted）的版本及原因 - 关注
+-和\-的缩进层级，顶格的是直接依赖，缩进的是传递依赖 - 如果看到
com.example:util:1.2.0被com.example:util:1.1.0omitted，说明旧版胜出，而你的代码调用的是 1.2.0 才有的方法
mvn dependency:resolve 和 javap 验证真实字节码
依赖树只是 Maven 的决策，最终加载进 JVM 的 class 文件可能还不是它——比如本地 ~/.m2/repository 被手动改过，或者 IDE 缓存没刷新。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 查实际加载的 jar 路径：在报错堆栈里找类名，然后用
mvn dependency:resolve -Dinclude=com.example:util确认坐标对应的真实文件路径 - 反编译验证方法是否存在：
javap -cp /path/to/util-1.1.0.jar com.example.Util | grep doWork，如果没输出，就是它的问题 - 注意：IDE 运行时 classpath 可能和
mvn exec:java不一致，务必在命令行复现问题再排查
怎么写 <exclusion> 和 <dependencyManagement> 才不翻车？
临时 exclude 某个传递依赖看似快，但容易漏掉其他模块；全局统一版本才是根治办法。关键是让所有模块都“闭嘴”，只认一个版本。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在父 pom 的
<dependencyManagement>中锁定版本：<artifactId>util</artifactId><version>1.2.0</version>，子模块只需声明 groupId/artifactId，不用写 version - 慎用
<exclusion>：只在明确知道某个依赖带进来的是坏版本时用，且要写全<groupId>和<artifactId> - 排除后务必重新跑
mvn dependency:tree，确认旧版本真的消失了，而不是被另一个路径又拉进来了
真正麻烦的从来不是找到哪个 jar 冲突，而是同一个 artifactId 在不同仓库里有多个语义不兼容的 “1.x” 版本，且没有遵循 semver。这时候得翻 changelog，甚至 diff 字节码——别跳过这步。
