SpringBoot多模块中同名自动配置类会因加载顺序导致覆盖或冲突，需通过检查自动配置报告、排查imports重复和版本冲突来确认生效情况，并采用归口注册、条件隔离、包路径区分、Bean覆盖配置（2.x）或@Primary重写（3.x）及profile控制加载顺序来解决。
SpringBoot多模块项目中，当模块A的自动配置类与模块B的同名自动配置类同时被加载时，会出现Bean定义冲突或后加载的配置覆盖前者的现象，导致预期功能失效。
确认自动配置是否真正生效
第一步：在主应用启动日志中搜索 【AutoConfigurationReport】 或启用 --debug 参数启动应用，观察 Spring Boot 自动配置报告中对应配置类的 status 字段是否为 matched；
第二步：检查各模块的 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件是否重复声明了相同全限定名的配置类——若存在重复，Spring Boot 会按 classpath 加载顺序取最后一个，造成“覆盖”假象；
第三步：用 IDE 的 Maven Dependencies 视图展开依赖树，确认是否存在两个不同版本的模块 jar 同时被引入（例如 module-a-1.0.0.jar 和 module-a-1.1.0.jar），版本冲突会导致部分配置类无法加载。
避免自动配置类互相覆盖
方法一：统一归口注册
将所有公共模块的自动配置类路径，集中写入主应用模块的 src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中，其他子模块不再提供该文件；【子模块必须删除自己的 AutoConfiguration.imports】，否则会触发并行加载，破坏加载顺序控制。
方法二：按环境条件隔离
在自动配置类上添加 @ConditionalOnProperty(name = "module.enabled", havingValue = "true")，并在各模块的 application.yml 中分别设置：module.enabled: false（禁用）或 module.enabled: true（启用），实现运行时开关控制；
方法三：利用包路径前缀区分
为不同模块的自动配置类指定唯一命名空间，例如模块A使用 com.example.a.config.AAutoConfig，模块B使用 com.example.b.config.BAutoConfig，并在各自 imports 文件中完整写出全限定名——Spring Boot 不会因类名相似而混淆，但类名重复且包路径相同则必然覆盖。
将 Spring Boot 2.7 项目升级到 Spring Boot 3.5 的实战流程，覆盖版本基线、依赖坐标替换、Jakarta 迁移、配置兼容、异步上下文传递改造与验证门禁。用于企业多模块 Maven 项目升级与排障。
解决 Bean 定义冲突
若两个模块都试图注册同名 Bean（如 @Service("userMapper")），需显式启用覆盖能力：
在主应用的 application.yml 中添加：
spring: main: allow-bean-definition-overriding: true
【Spring Boot 3.x 已彻底移除此配置，不可用于 3.0+ 版本】；
对于 Spring Boot 3.x，改用 @Primary + 显式 @Bean 声明方式，在主应用配置类中重写目标 Bean，并确保其构造/注入逻辑兼容原实现。
强制指定配置加载顺序
步骤一：在主应用的 src/main/resources/application.yml 中明确指定 profile 激活顺序：
spring: profiles: active: dev,module-a,module-b
步骤二：为每个模块创建独立 profile 配置文件，如 application-module-a.yml、application-module-b.yml，并将模块专属配置（如数据源 URL、缓存策略）移入其中；
步骤三：在各模块的自动配置类上添加 @ConditionalOnProfile("module-a") 等限定注解，确保仅当对应 profile 激活时才加载该模块配置。
