NoSuchMethodError是运行时错误，因JVM加载的类版本缺失编译时存在的方法；需从堆栈提取签名→查版本兼容性→用dependency:tree定位冲突路径→exclusions排除旧版→显式声明统一版本→加-verbose:class或代码打印验证实际加载jar。
直接定位并切断冲突源头，而不是等报错再救火。
看懂 NoSuchMethodError 的真实含义
这不是编译失败，而是运行时“认错人”：你代码里调用的方法，在编译时存在，但 JVM 加载的那个类版本里根本没有它。常见于 okhttp、log4j、jackson 等高频依赖——比如调用 Logger.atTrace()，却加载了不带该方法的 log4j-core 2.11，而项目里实际还混着 2.17。
关键三步确认：
- 从异常堆栈第一行提取完整方法签名，例如：org.apache.logging.log4j.util.LoaderUtil.getClassLoaders()[Ljava/lang/ClassLoader;
- 查 Javadoc 或官网 Release Notes，确认这个方法最早出现在哪个版本
- 反向验证：你代码里写的调用，是否真的只在新版本中才有？别被 IDE 补全误导
用 dependency:tree 快速揪出冲突路径
不要只看 IDEA 的依赖图，它有时会隐藏传递路径。进到出问题的模块根目录（不是父工程），执行：
立即学习“Java免费学习笔记（深入）”；
mvn dependency:tree -Dincludes=org.apache.logging:log4j-core
重点观察：
- 同一 groupId:artifactId 出现多个版本（如 log4j-core:2.11 和 2.17）
- 它们分别来自哪条依赖链（A → B → log4j-core:2.11 vs A → C → log4j-core:2.17）
- 路径长度是否不同——Maven 默认选最短路径的那个版本
如果两条路径长度一样，就看 pom.xml 里谁声明得更靠前。
精准排除 + 强制统一版本
光 exclude 不够，必须确保最终生效的是你要的那个版本。
- 在根 pom 或出问题模块的 pom 中，显式声明你要的版本（如 log4j-core 2.20.0），scope 为 compile，且放在所有其他依赖之前
- 对已知引入旧版本的依赖，加 <exclusions> 切断其传递依赖
- 示例：某 SDK 引入了 okhttp 3.4.2，而你需要 4.12.0，就在引用该 SDK 时排除它：
<groupId>com.example</groupId>
<artifactId>legacy-sdk</artifactId>
<exclusions>
<exclusion>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
</exclusion>
</exclusions>
</dependency>
上线前加一道保险：验证实际加载的 Jar
本地跑通 ≠ 线上不出事。启动时加上 JVM 参数：
-verbose:class -Xlog:classpath=debug
或更轻量的方式，在 main 方法开头加一行：
System.out.println(Logger.class.getProtectionDomain().getCodeSource().getLocation());直接打印出 Logger 类实际从哪个 jar 加载——这是唯一权威答案，比任何分析工具都准。
