Spring Boot自动装配外部库Jar报ClassDefNotFound异常

抛出NoClassFoundException核心是运行时类路径下找不到libB的相关类，和包扫描配置没有直接关系——包扫描配置错误只会抛出NoSuchBeanDefinitionException，不会报类不存在。
这个场景下90%的概率是libA、libB的打包方式错误：如果这两个外部库用Spring Boot默认的spring-boot-maven-plugin打了可执行fatjar，生成的jar包是Spring Boot专属的嵌套结构（类都放在BOOT-INF/classes、依赖放在BOOT-INF/lib下），不是标准的Maven/Gradle可依赖jar结构，主应用SpringApp引入libA时，Maven/Gradle无法识别libA嵌套的libB依赖，自然不会把libB的类加载到类路径里。
剩下小概率原因是libA声明libB依赖时加了optional=true、provided范围，或者SpringApp依赖时主动排除了libB，导致依赖传递断裂。

按以下顺序排查修复：

• 修正libA、libB的打包配置
  两个库不要直接打可执行Spring Boot fatjar作为对外依赖产物，修改库模块的spring-boot-maven-plugin配置：
  如果库不需要独立运行，直接跳过repackage阶段，打普通jar包即可：

  <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <configuration>
          <skip>true</skip>
      </configuration>
  </plugin>
  

  如果库本身需要支持独立运行，可以给可执行包单独指定classifier，避免可执行fatjar覆盖普通依赖包：

  <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <configuration>
          <classifier>exec</classifier>
      </configuration>
  </plugin>
  

• 校验依赖传递链路
  在SpringApp项目根目录执行依赖检查命令：Maven项目执行mvn dependency:tree，Gradle项目执行./gradlew dependencies，在输出的依赖树里确认libB是否被正常引入。
  如果找不到libB，先检查libA中libB的依赖范围：不要设置为optional、provided，使用默认的compile范围即可；同时检查SpringApp的依赖配置，确认没有主动排除libB相关依赖。
• 补全Bean扫描配置（可选，规避后续Bean找不到问题）
  你当前启动类只配置了扫描libA的根包com.example，如果libB的Bean所在根包不在这个路径下，类加载正常后还会报Bean找不到的错误，两种方式解决：
  1. 把libB的根包路径补充到scanBasePackages配置中，例如@SpringBootApplication(scanBasePackages = {"com.example", "com.b.lib"})，路径替换为libB实际的根包即可。
  2. 更规范的做法是给libA、libB添加Spring Boot自动装配能力：在库的resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中声明库自身的配置类，主应用不需要手动配置包扫描，Spring Boot启动时会自动加载所有声明的配置类和Bean，不需要硬编码包路径。

内容的提问来源于stack exchange，提问作者vhdl