Spring Boot多环境配置冲突本质是配置源优先级覆盖导致，需按命令行参数→JVM属性→环境变量→外部配置→内部配置顺序排查，重点关注Active profiles日志、文件命名位置合规性、YAML缩进及properties屏蔽yml等问题。
SpringBoot多环境自动配置冲突本质是不同来源的配置项互相覆盖导致Bean加载异常、属性值错乱或Profile未生效，必须严格按优先级链逐层排查才能定位真实冲突点。
确认当前生效的配置源优先级顺序
SpringBoot配置加载遵循固定优先级链：命令行参数 → JVM系统属性（-D）→ 操作系统环境变量 → 外部配置文件（./config/）→ 类路径内部配置文件（classpath:/config/ → classpath:/）。后加载的配置会覆盖先加载的同名属性。
这一步操作起来很简单，直接在启动日志里搜索【Active profiles】和【Loaded config file】两处关键输出，就能看到实际加载了哪些文件、按什么顺序加载的。
注意：若项目用了Spring Cloud，bootstrap.yml会比application.yml更早加载，且其配置不可被后续配置覆盖——这是很多开发者踩坑的根源。
检查spring.profiles.active是否被高优先级方式覆盖
当application.yml中写了spring.profiles.active=dev，但实际加载的是prod配置，大概率是命令行或环境变量强行覆盖了它。
方法一：检查启动命令是否带--spring.profiles.active=prod参数
方法二：检查操作系统环境变量是否设置了SPRING_PROFILES_ACTIVE=prod（Linux/macOS用env | grep SPRING，Windows用set SPRING）
方法三：检查IDEA的Run Configuration里VM options是否含-Dspring.profiles.active=prod
【环境变量和命令行参数优先级高于配置文件，哪怕application.yml里写死active也没用】
将 Spring Boot 2.7 项目升级到 Spring Boot 3.5 的实战流程，覆盖版本基线、依赖坐标替换、Jakarta 迁移、配置兼容、异步上下文传递改造与验证门禁。用于企业多模块 Maven 项目升级与排障。
验证application-{profile}.yml命名与位置是否合规
第一步：确认文件名严格为application-dev.yml、application-prod.yml，不能是application_dev.yml或app-dev.yml
第二步：确认文件放在正确路径——必须放在classpath根目录（即src/main/resources/），不能放在子包里
第三步：检查YAML语法是否合法，尤其注意缩进和冒号后空格。一个错位的空格会导致整个文件解析失败，SpringBoot静默跳过该文件而不报错
第四步：确认没有同时存在application-dev.yml和application-dev.properties——【同名properties文件会完全屏蔽yml文件】
排查自动配置类加载顺序冲突
第一步：启用debug模式启动应用，添加--debug参数
第二步：在控制台搜索AutoConfigurationReport，找到所有被排除（excluded）和匹配（matched）的自动配置类
第三步：重点查看@ConditionalOnMissingBean、@ConditionalOnClass等注解的判断结果——如果自定义DataSourceConfig没生效，大概率是官方HikariAutoConfiguration先加载并创建了Bean，导致你的条件不满足
第四步：强制调整加载顺序，在自定义配置类上加@Order(Ordered.HIGHEST_PRECEDENCE)或使用@AutoConfigureBefore(HikariAutoConfiguration.class)
