多模块 Maven 项目中“方法找不到”错误通常是类加载器隔离所致：同名类被不同 ClassLoader 加载，导致运行时方法签名不匹配；需检查 scope、依赖路径、ClassLoader 来源并统一公共模块加载边界。
多模块 Maven 项目中出现“方法找不到”（如 NoSuchMethodError、AbstractMethodError 或运行时报错提示某个方法不存在），但编译通过、IDE 不报红，往往不是代码写错了，而是类加载器层面的隔离问题——不同模块的类被不同的 ClassLoader 加载，导致看似相同的类（同名、同包）实则属于不同类空间，方法签名无法匹配。
确认是否为类加载器隔离引发的问题
先排除编译期和依赖版本问题，再聚焦类加载。满足以下特征时，高度怀疑是类加载器作用域隔离所致：
- 错误发生在运行时，而非编译期（IDE 和
mvn compile均无报错）； - 报错类型为
NoSuchMethodError或AbstractMethodError，且方法确实存在于源码中； - 涉及跨模块调用，尤其是 A 模块调用 B 模块提供的接口/抽象类，而 B 模块又被 C 模块以不同方式（如
provided、runtime、或嵌套依赖）引入； - 在 Spring Boot 环境下，该方法所属类由不同 ClassLoader 加载（例如：启动类由
LaunchedURLClassLoader加载，而某工具类由PluginClassLoader或自定义 ClassLoader 加载）。
检查依赖作用域与传递路径
provided、runtime、test 等 scope 会直接影响类是否进入运行时 classpath，进而影响哪个 ClassLoader 能加载它。
- 若某模块（如
common-utils）声明了provided web-service）直接依赖它，而运行环境（如 Tomcat、Flink、Spring Boot DevTools）未提供该 jar，则调用其方法时会因类缺失或版本错配而失败； - 使用
mvn dependency:tree -Dverbose查看目标类（如com.example.api.ServiceApi）的完整引入路径，确认是否被多个模块以不同版本、不同 scope 引入； - 特别注意
spring-boot-maven-plugin的repackage行为：它会将所有 runtime 依赖打平进 fat jar，但若某依赖被标记为provided，则不会被打入，此时若该依赖又在插件类路径中存在（如 IDEA 的 Maven 插件自带旧版 slf4j），就极易触发NoSuchMethodError。
验证类的实际加载来源
运行时打印类的 ClassLoader 和位置，是最直接的判断依据。
- 在出错方法调用前加日志：
System.out.println(ServiceApi.class.getClassLoader());System.out.println(ServiceApi.class.getProtectionDomain().getCodeSource()); - 对比调用方类与被调用方类的 ClassLoader 是否一致（如都是
LaunchedURLClassLoader，或一个是AppClassLoader、另一个是PluginClassLoader）； - 若两者 ClassLoader 不同，且
getCodeSource()指向不同 jar（比如一个来自target/lib/common-1.2.jar，另一个来自~/.m2/repository/.../common-1.0.jar），说明发生了类加载器隔离+版本冲突。
统一类加载边界，避免隐式多加载
核心原则：让同一语义的类（尤其 API 接口、DTO、常量类）始终由同一个 ClassLoader 加载。
- 将公共契约模块（如
api、dto、exception）设为compilescope，并禁止在任何子模块中用provided引入它； - 禁用父 pom 中对公共模块的
spring-boot-maven-plugin继承（见知识库“坑1”），防止其被错误 repackage 成可执行 jar； - 在 Spring Boot 启动类上显式配置扫描范围，避免因包结构分散导致部分 bean 由不同 ClassLoader 初始化；
- 如需自定义 ClassLoader（如插件化场景），确保 API 类优先从 parent ClassLoader 加载（即启用
Thread.currentThread().setContextClassLoader(parent)或设置parentFirst = true）。
