解决项目实践中 java.lang.NoSuchMethodError：的问题

网罗开发（小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

前言

在日常 Java 开发中，大家应该都见过这种报错：

java.lang.NoSuchMethodError: '返回类型 包名.类名.方法名(参数列表)'

这个错误看似“方法不存在”，但实际上大多数情况下方法明明写在代码里，IDE 编译也能过，就是运行时突然报错。本文就带大家拆解一下问题的本质，结合实际案例演示如何排查和解决。

问题背景：编译和运行时依赖不一致

NoSuchMethodError 并不是说你拼写错了方法，而是 运行时环境加载的类和编译时使用的类不一样。

比如：

• 你在开发时引入了 1.2 版本的依赖库，编译时用到了其中新增的方法。
• 但实际运行时，项目里加载的是 1.0 版本的依赖库，那个方法还没被实现。
• 结果：运行时找不到方法，就报 NoSuchMethodError。

这个问题在 Maven / Gradle 项目、Spring Boot 多模块项目里特别常见，因为依赖传递很容易导致版本冲突。

Demo 示例：重现 NoSuchMethodError

我们先来写个最小复现案例。

依赖库（lib-demo v1.0）

// lib-demo v1.0
package com.example.lib;public class HelloService {public String sayHello(String name) {return "Hello " + name;}
}

新版本依赖库（lib-demo v1.2）

// lib-demo v1.2
package com.example.lib;public class HelloService {public String sayHello(String name) {return "Hello " + name;}// 新增方法public String sayHi(String name) {return "Hi " + name;}
}

主程序

package com.example.app;import com.example.lib.HelloService;public class Main {public static void main(String[] args) {HelloService service = new HelloService();System.out.println(service.sayHi("Tom")); // 调用新方法}
}

如果你在 编译时用的是 lib-demo 1.2，一切正常。
但是运行时只要 classpath 里加载的是 lib-demo 1.0，就会报错：

Exception in thread "main" java.lang.NoSuchMethodError: 'java.lang.String com.example.lib.HelloService.sayHi(java.lang.String)'

如何排查？

遇到这个问题，排查的思路一般分三步：

1. 检查依赖树

如果是 Maven 项目，可以用：

mvn dependency:tree

Gradle 项目可以用：

./gradlew dependencies

看看是不是有多个版本的 lib-demo 被引入了。

例如：

[INFO] +- com.example:lib-demo:jar:1.2:compile
[INFO] \- com.other:some-lib:jar:1.0:compile\- com.example:lib-demo:jar:1.0:compile

很明显，some-lib 又带进来了低版本的依赖。

2. 确认最终运行的 JAR 包版本

即使在 pom.xml 里写的是 1.2，运行时可能还是加载到 1.0。
可以在运行时加一句：

System.out.println(HelloService.class.getProtectionDomain().getCodeSource().getLocation());

这样你就能打印出 JVM 实际加载的 HelloService 来自哪个 JAR 包。

3. 清理缓存，确保依赖一致

有时候 Maven 本地仓库里旧版本没更新，或者打包工具没清理干净。
建议执行：

mvn clean install -U

确保本地缓存和远端一致。

解决方案

针对这种问题，常见的解决方式有几种：

方案一：排除冲突依赖

在 pom.xml 里明确排除掉低版本依赖：

<dependency><groupId>com.other</groupId><artifactId>some-lib</artifactId><version>1.0</version><exclusions><exclusion><groupId>com.example</groupId><artifactId>lib-demo</artifactId></exclusion></exclusions>
</dependency>

方案二：锁定依赖版本

使用 Maven 的 <dependencyManagement> 或 Gradle 的 resolutionStrategy 来强制使用指定版本：

<dependencyManagement><dependencies><dependency><groupId>com.example</groupId><artifactId>lib-demo</artifactId><version>1.2</version></dependency></dependencies>
</dependencyManagement>

Gradle:

configurations.all {resolutionStrategy {force 'com.example:lib-demo:1.2'}
}

方案三：清理并重建

有时候光是本地缓存问题，直接清理一下就能解决：

mvn dependency:purge-local-repository

或者直接删掉 ~/.m2/repository 对应目录，重新构建。

实际场景中的意义

我自己在做一个 Spring Boot 多模块项目的时候就遇到过类似的坑：

• A 模块用的是某个库的 2.x 版本；
• B 模块因为依赖了一个老库，又把 1.x 的版本带进来了；
• 结果上线之后，某个 API 调用直接报 NoSuchMethodError，排查半天才发现是依赖冲突。

这种问题的危险在于：编译没问题，运行才炸，所以一定要养成上线前检查依赖树的习惯。

总结

java.lang.NoSuchMethodError 本质上就是 编译和运行时依赖版本不一致。

解决思路：

1. 查依赖树，看看是不是被拉了旧版本。
2. 确认运行时加载的 JAR 包是不是正确。
3. 必要时排除、锁定依赖版本，并清理缓存。

这样一套流程走下来，大多数问题都能定位并解决。