在 Spring Boot 与 Spring Cloud 项目里，bootstrap.yml 和 application.yml 是高频配置文件，很多开发者容易混淆两者的加载时机、使用场景，尤其在 Spring Boot 2.4+ 版本后，配置机制又有重大调整。本文用清晰易懂的方式，帮你彻底理清两者差异，避开配置踩坑。

---

一、先明确核心归属：谁是谁的“专属配置”

先分清两个文件的技术归属，这是理解差异的基础：

• 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 即可正常加载，适合老项目迁移。

---

五、一张表总结核心区别

对比维度	bootstrap.yml	application.yml
技术归属	Spring Cloud 特有	Spring Boot 原生
加载时机	应用上下文创建前	应用上下文初始化中
上下文角色	父上下文（引导）	子上下文（主应用）
配置优先级	低（被 application 覆盖）	高（覆盖 bootstrap）
核心用途	配置中心、加密、服务元信息	端口、数据源、业务配置
新版支持	2.4+ 默认禁用，需手动开启	默认支持，推荐使用
纯 Boot 项目	不加载	必须加载

---

六、最佳实践建议

1. 新项目（Spring Boot 2.4+）：直接用 application.yml + spring.config.import，弃用 bootstrap，简化配置。
2. 旧项目升级：先引入 spring-cloud-starter-bootstrap 兼容，再逐步迁移到新规范。
3. 配置分工：bootstrap 只做“引路”，application 只做“业务”，不混用、不冗余。
4. 敏感信息：配置中心地址、密钥等，优先用环境变量注入，不硬编码。

---

总结

bootstrap.yml 是 Spring Cloud 为了解决远程配置前置加载的特殊方案，application.yml 是 Spring Boot 标准主配置；新版 Spring Cloud 已用更简洁的 spring.config.import 统一配置入口，bootstrap 逐渐成为兼容方案。

理解加载机制、分清场景、遵循新版规范，就能彻底搞定这两个配置文件，避开 90% 的配置相关启动异常。