核心在于统一主配置入口，禁用子模块主配置文件；主应用application.yml为唯一权威源，子模块不得含application.yml，需差异化配置时用profile-specific文件（如application-test.yaml），并通过@propertysource显式加载非重名properties，确保单个@springbootapplication入口、合理包结构及父pom统一版本仲裁。
多模块配置共享冲突，核心在于“多个模块都想管配置，结果谁也管不好”。解决的关键不是压哪个模块让步，而是明确谁主责、谁辅助、谁隔离。
统一主配置入口，禁用子模块主配置文件
主应用（如 web 模块）的 application.yml 是唯一权威配置源。所有数据库、Redis、日志等通用配置必须集中在此处定义。子模块（如 jpa、security、common）不得包含自己的 application.yml 或 application.properties，否则会触发 Spring Boot 多配置加载冲突，导致属性覆盖或环境感知错乱。
- 若子模块需差异化配置（如测试专用数据源），应使用 profile-specific 文件，例如 application-test.yaml，并仅在对应 profile 下生效
- 子模块中可保留 xxx.properties（如 data-dev.properties），但必须通过 @PropertySource 显式加载，且不能与主配置项重名
- 构建时确保子模块打包为 jar（非 spring-boot-maven-plugin repackage），避免嵌入启动类和冗余配置
确保单个 @SpringBootApplication 入口点
整个项目运行时只能有一个 Spring Boot 应用上下文。若子模块误加了 @SpringBootApplication 或 @EnableAutoConfiguration，会导致容器重复初始化、Bean 注册冲突甚至启动失败。
- 子模块只提供组件（@Service、@Repository、@Configuration），不启动容器
- 主模块的启动类包路径应处于最外层（如 com.example.app），子模块包路径需在其下（如 com.example.jpa、com.example.security），以保障组件扫描自然覆盖
- 若子模块含自动配置类（@ConditionalOnMissingBean 等），须确保其被主模块通过 @Import 或 spring.factories 主动引入，而非自动触发
依赖版本由父 POM 统一仲裁，子模块不声明版本
版本混乱常源于子模块自行指定框架版本（如 spring-security-web、tomcat-embed-core），绕过了 Spring Boot 的 spring-boot-dependencies 版本管理机制。
- 父 POM 的
中导入 spring-boot-dependencies，并锁定关键第三方库（如 mybatis-plus、redisson）版本 - 子模块的 pom.xml 中所有依赖只写 groupId 和 artifactId，不写 version；security 等可选功能用
true 标记，避免传递给不需要的模块 - 用 mvn dependency:tree -Dverbose 定位冲突源头，再用
精准排除传递进来的低/高版本依赖
跨模块配置对象用构造注入，不依赖 @Value 魔法绑定
当多个模块需共用同一组配置（如 API 密钥、超时参数），直接在各处用 @Value("${api.timeout}") 易导致硬编码、类型不安全、测试难 mock。
- 定义专用配置类（如 ApiProperties），用 @ConfigurationProperties(prefix = "api") 绑定
- 该类只在主模块中启用（@EnableConfigurationProperties(ApiProperties.class)），并通过构造函数注入到各模块的服务中
- 避免在子模块中重复定义同名配置类——Spring 容器会报 ConflictingBeanDefinitionException
