一、先明确核心归属：谁是谁的“专属配置”
先分清两个文件的技术归属，这是理解差异的基础：

application.yml：Spring Boot 原生标配，所有 Spring Boot 项目默认加载，是应用的主配置文件，和 Spring Cloud 无强绑定。
bootstrap.yml：Spring Cloud 扩展特性，纯 Spring Boot 项目不会加载，只有引入 Spring Cloud 相关依赖后才可能生效。
简单记：application 是标配，bootstrap 是微服务专属。

二、核心差异一：加载顺序与上下文层级
两者最本质的区别，体现在启动加载阶段和上下文优先级：

1. 加载时机
bootstrap.yml：在应用主上下文创建前加载，由 Spring Cloud 引导上下文（Bootstrap Context）优先解析，属于“启动前置配置”。
application.yml：在应用上下文初始化过程中加载，是容器启动的标准配置环节。
2. 优先级与覆盖规则
这里有个常见误区：不是加载早就优先级高。
正确规则：同名配置项，application.yml 覆盖 bootstrap.yml。
原因：Bootstrap 是父上下文，Application 是子上下文，Spring 配置体系中子上下文优先级高于父上下文，主应用配置拥有最终决定权。

三、核心差异二：使用场景（该放什么配置）
两者分工明确，不要混用，否则会导致配置不生效或启动异常。

✅ bootstrap.yml 适用场景（微服务引导配置）
只放连接外部配置中心的元配置，解决“先有鸡还是先有蛋”问题——应用要拉远程配置，得先知道配置中心地址：

配置中心接入：Nacos、Consul、Spring Cloud Config Server 地址、命名空间、分组。
安全相关：Vault 敏感信息配置、加密密钥（encrypt.key）。
服务核心标识：spring.application.name（部分旧版规范）、服务注册元数据。
示例（Nacos 配置中心）：

spring:
application:
name: user-service
cloud:
nacos:
config:
server-addr: 127.0.0.1:8848
namespace: dev
group: DEFAULT_GROUP

application.yml 适用场景（应用业务配置）
放应用运行时的常规配置，和业务、容器运行相关：

服务端口：server.port
数据源：spring.datasource 相关连接信息
中间件：Redis、RabbitMQ、Elasticsearch 配置
日志、监控、线程池、自定义业务参数
示例：

server:
port: 8080
spring:
datasource:
url: jdbc:mysql://localhost:3306/user_db
username: root
password: 123456
logging:
level:
root: info
 

四、关键变革：Spring Boot 2.4+ 后，bootstrap 默认失效
这是新版项目最容易踩的坑：Spring Boot 2.4 及以上 + 对应 Spring Cloud 版本，默认移除 Bootstrap 上下文。

1. 为什么这么改？
简化启动流程：去掉双上下文，减少启动耗时与复杂度。
统一配置入口：用 spring.config.import 替代 bootstrap，所有配置收敛到 application.yml。
减少“黑魔法”：开发者不用再记“某些配置必须放 bootstrap 才生效”。
2. 新版两种解决方案
方案一（官方推荐）：用 spring.config.import 替代
直接在 application.yml 导入远程配置，无需 bootstrap：

spring:
config:
import: optional:nacos://127.0.0.1:8848?namespace=dev&group=DEFAULT_GROUP
application:
name: user-service
 optional: 表示配置中心不可用时不报错，适合本地开发调试。

方案二（兼容旧项目）：手动启用 bootstrap
引入依赖，恢复旧版加载机制：

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
引入后，bootstrap.yml 即可正常加载，适合老项目迁移。