Spring Boot配置文件的核心答案：一切外部化配置都从application.yml或application.properties起步，选YAML格式，用多环境文件拆分，配@ConfigurationProperties绑定。
Spring Boot配置文件格式选哪种
刚接触Spring Boot的开发者，第一个纠结通常是配置文件格式问题，application.properties是老牌选手，application.yml是后起之秀，两者功能等价，spring boot官方文档明确说两种格式都支持，但YAML在可读性和层级表达上明显占优。
application.properties和application.yml有什么区别
properties文件是扁平结构,用点号分隔每个配置项：
spring.datasource.url=jdbc:mysql://localhost:3306/test spring.datasource.username=root spring.datasource.password=123456
yml文件用缩进表示层级关系：
spring:
datasource:
url: jdbc:mysql://localhost:3306/test
username: root
password: 123456
区别不在于功能，在于表达方式，配置文件一大痛点就是层级一深，properties写法容易看花眼，yml的缩进结构让层级一目了然，行业共识认为，新项目选YAML格式，维护成本更低，但老项目升级改造时保留properties完全没问题，spring boot底层会统一解析成PropertySource,不存在性能差异。
配置文件里写什么内容
配置文件管理三类内容：连接外部资源的信息（数据库、Redis、MQ）、业务开关和参数（如限流阈值）、框架行为的调整项（如端口号、日志级别），凡是需要部署后修改的东西，都应该进配置文件而不是写死在代码里，这是Spring Boot外部化配置机制的核心思想。
Spring Boot多环境配置怎么切换
开发环境、测试环境、生产环境的配置不一样，数据库地址不同、日志级别不同、接口密钥不同，Spring Boot提供了spring.profiles.active这个开关,一行参数解决多环境问题。
多环境文件命名规则
文件命名遵循application-{profile}.yml的格式：
application.yml # 公共配置
application-dev.yml # 开发环境
application-test.yml # 测试环境
application-prod.yml # 生产环境启动时通过命令行参数激活对应的profile：
java -jar app.jar --spring.profiles.active=prod
生产环境部署脚本里把profiles.active指到prod就完成了环境切换，这个机制的实用之处在于，公共配置放基础文件，差异配置按环境拆分,互相不污染。
多环境配置最佳实践
实际项目里，公共配置只放所有环境一致的项，按环境区分的配置（数据库连接、日志路径、第三方密钥）全部放对应profile文件中，启动命令里指定profile,框架自动加载对应文件。
用打包参数动态指定profile也是常见做法，Maven的profile配合Spring profile一起用：
<profiles>
<profile>
<id>prod</id>
<properties>
<activatedProperties>prod</activatedProperties>
</properties>
</profile>
</profiles>
构建命令加-Pprod，然后pom里用activatedProperties占位，这样打包阶段就把环境参数嵌进启动脚本里，这套流程在很多公司已经标准固化，部署时不用手动改配置，避免了环境参数写错导致的事故。
Spring Boot配置文件加载顺序
配置文件加载顺序决定了谁覆盖谁，这是排查配置不生效问题的关键，Spring Boot的配置加载优先级从高到低排列，命令行参数 > Java系统属性 > 操作系统环境变量 > 外部application.yml > 内部application.yml。
配置覆盖的层级关系
举个例子，application.yml里把端口写成8080，部署时用–server.port=9090启动，最终生效的是9090，因为命令行参数优先级最高，配置文件优先级最低,很多运维事故都源于这个顺序没搞清楚。
开发调试时的坑更常见：改了application.yml里的配置，重启用的是环境变量里过时的配置，排查思路就是从上往下逐层检查，先看命令行参数,再看系统环境变量。
bootstrap.yml和application.yml的区别
Spring Cloud项目中常见bootstrap.yml和application.yml并存，bootstrap.yml由父级ApplicationContext加载，优先于application.yml，bootstrap主要用于连接配置中心（如Nacos、Spring Cloud Config）。
逻辑上的分工是：bootstrap负责拉取远程配置，application负责本地业务配置，新版Spring Cloud已经弱化了bootstrap的强制使用，用spring.config.import替代，但存量项目里bootstrap.yml依然很常见。
Spring Boot配置绑定到Java对象
配置不经过绑定直接用@Value注入，项目大了以后维护非常痛苦。@ConfigurationProperties是把配置映射到Java对象的规范做法。
@ConfigurationProperties使用步骤
先建一个配置类,定义好属性和默认值：
@Component
@ConfigurationProperties(prefix = "app.order")
public class OrderProperties {
private int timeout = 3;
private List<String> retryUrls = new ArrayList<>();
// getter setter
}
配置文件里这样写：
app:
order:
timeout: 5
retry-urls:
- http://order-service-1
- http://order-service-2
启动后OrderProperties对象自动填充了配置值，业务代码里直接注入使用。复杂配置用@ConfigurationProperties，简单键值对用@Value,这是实践中总结出来的分界线。
配置校验和复杂类型处理
生产环境对配置正确性要求高,可以引入校验注解：
@Validated
@ConfigurationProperties(prefix = "app.order")
public class OrderProperties {
@NotNull
private String callbackUrl;
@Min(value = 1, message = "timeout must >= 1")
private int timeout;
}
配置错误在启动时立刻报错，而不是运行到调用点才炸，List、Map、嵌套对象都能绑定，这是@Value不具备的能力。
Spring Boot配置不生效怎么办
排查配置不生效，沿着三个方向走：优先级的覆盖、profile的激活、配置项的拼写，把这三点都检查过,多数问题都能找到根因。
检查优先级和profiles
先用启动日志确认实际生效的profile是什么，Spring Boot启动时会输出”Starting Application on…”和”Active Profiles”信息，日志里没有显示profiles，说明没激活任何环境专属文件，application.yml里的公共配置是唯一的配置来源。
检查拼写和Config Data导入
配置项拼写错误是新手最容易踩的坑，spring.datasource.url和spring.datasource.jdbc-url都有可能出现，不同的连接池框架识别不同的键名，Druid用前者，HikariCP两者都认，检查方法简单,看框架官方文档里的配置键清单。
Spring Boot 2.4以后引入了spring.config.import，多配置文件的导入逻辑变了些，原来spring.profiles.include的用法在新版本里依然兼容，但spring.config.import是更明确的声明式导入。
Spring Boot配置文件内容安全
配置里藏着数据库密码、密钥，这些问题不能直接明文写在文件里，Git仓库里提交了生产密码,一旦仓库公开就是安全事件。
敏感信息的处理方式
最基础的做法是环境变量替换，Jasypt加密是常见方案，用对称密钥对配置值加密，启动时传入解密密钥，搭Nacos或Spring Cloud Config，配置中心集中管理敏感信息，权限控制更细,密钥轮换也更方便。
Jasypt的使用路线：加密工具生成密文，配置文件写ENC(密文)，启动时通过环境变量传入解密密码。日常开发用环境变量，生产环境用配置中心，安全性提升的同时,开发体验没有太多折损。
Spring Boot配置文件常见问题解答
配置文件优先级中，哪一层对覆盖内部配置最有效？
命令行参数优先级最高，多环境场景下用–spring.profiles.active指定环境，覆盖内部配置文件时直接用–key=value格式，这个方式在CI/CD流水线中非常实用,灵活度和可控性都最高。
bootstrap.yml和application.yml同时存在，写哪个生效？
bootstrap.yml先加载，需要从配置中心拉取配置时写在bootstrap.yml里，业务相关配置放application.yml，远程配置优先于本地application.yml的机制,保证配置中心的数据能覆盖本地的默认值。
配置项太多，如何分文件管理而不是堆在一个application.yml里？
用spring.config.import拆分模块，按业务域拆分出datasource.yml、redis.yml、mq.yml，每个文件管理一类配置，在application.yml里用import引入，这样配置文件的职责边界清晰，多人协作时各自维护自己的模块文件,冲突概率显著降低。