maven依赖冲突导致nosuchmethoderror或classnotfoundexception，需按四步解决：第一步用mvn dependency:tree -dverbose定位被省略的冲突版本；第二步通过-dincludes过滤并分析依赖路径；第三步选择排除依赖、版本锁定或ide辅助验证；第四步清理编译并验证是否彻底解决。
项目突然报出NoSuchMethodError或ClassNotFoundException，明明pom里写了依赖却找不到类，十有八九是Maven在背后悄悄替你做了版本裁决——它把某个依赖的多个版本中只留了一个，而你恰好需要被删掉的那个。
第一步：用命令精准定位冲突源头
打开终端，进入项目根目录，执行：
mvn dependency:tree -Dverbose
这个命令会输出完整依赖树，并明确标出哪些依赖因冲突被省略。关键要看带 【omitted for conflict】 的行——它告诉你哪个版本被踢出去了、谁引入的、为什么被踢。
如果输出太长难定位，直接过滤目标依赖，比如查 commons-lang3：
mvn dependency:tree -Dincludes=org.apache.commons:commons-lang3
注意：不要只扫一眼就下结论。同一依赖可能从 A→B→C 和 D→E 两条路径进来，路径长度不同，Maven 会按“最短路径优先”原则选一个版本，另一个自动丢弃——【被丢弃的未必是错的，但一定是你运行时缺方法的根源】。
第二步：看清依赖路径再动手排除
找到冲突依赖后，必须确认它是谁带进来的。比如发现 guava:31.0 被省略，而项目实际加载的是 guava:30.0，那就得查清楚：31.0 是哪个第三方库传进来的？
执行：
mvn dependency:tree -Dincludes=com.google.guava -Dverbose
输出中会看到类似：
[INFO] +- com.example:service-core:1.2.0
[INFO] | \- com.google.guava:guava:31.0
[INFO] \- org.springframework.boot:spring-boot-starter-web:3.2.0
[INFO] \- com.google.guava:guava:30.0
这说明 service-core 引入了 31.0，而 Spring Boot 引入了 30.0，Maven 选了更短路径（后者），于是 31.0 被 omit。此时若 service-core 内部调用了 31.0 特有的 API，就会崩。
第三步：针对性排除或统一版本
方法一：依赖排除（适用于只想干掉某条路径的传递依赖）
在 pom.xml 中找到引入高版本的依赖项，在其
方法二：版本锁定（适用于全项目需统一某依赖）
在 pom.xml 的
这样所有模块都会强制使用 31.0，无论谁传进什么版本。
方法三：IDE辅助验证（IntelliJ IDEA 用户专属）
右键 pom.xml → Maven → Show Dependencies → 切换到 Conflicts 标签页。红色标记即为被忽略的冲突版本，白色为最终生效版本。点击任一冲突项，右侧会显示完整依赖路径——比命令行更直观，尤其适合多模块项目。
第四步：验证是否真正解决
执行 mvn clean compile，观察编译是否通过；
再运行 mvn dependency:tree | grep guava（替换成你的目标依赖），确认输出中不再出现 【omitted for conflict】；
最后启动应用，触发相关业务逻辑，验证 NoSuchMethodError 是否消失。
如果仍有问题，回到第一步，重新跑 -Dverbose，重点检查是否有其他间接路径又偷偷引入了旧版本——【一次排除不等于一劳永逸，Maven 的传递性会让漏网之鱼反复出现】。
