从 bootstrap.yml 到 Config Data 的一次架构升级

在 Spring Cloud 项目中，很多人都有过这样的经历：

• 旧项目中，Nacos / Config Server 必须写在bootstrap.yml
• 新项目中，却发现直接写在application.yml也能生效
• 再一看启动顺序和优先级，更是让人一头雾水

这并不是“规范变松了”，
而是Spring Boot 在 2.4 版本之后，对配置加载模型做了一次彻底升级。

一、先给结论

新版本之所以可以把配置写在application.yml，
不是因为application.yml变强了，
而是 Spring Boot 的“配置加载机制”变了。

👉分水岭版本：Spring Boot 2.4

二、老版本为什么“必须用 bootstrap.yml”？（≤ 2.3）

1️⃣ 老模型：双 Context 启动机制

在 Spring Boot 2.3 及以前，Spring Cloud 采用的是：

Bootstrap Context（引导上下文） ↓ Application Context（应用上下文）

2️⃣ bootstrap.yml 的真实职责

bootstrap.yml属于Bootstrap Context，作用只有一个：

在 Spring 容器真正启动前，先加载“配置中心相关信息”

典型内容包括：

• spring.application.name
• spring.profiles.active
• spring.cloud.nacos.server-addr
• 配置中心认证信息

3️⃣ 为什么 application.yml 不行？

因为在老模型中：

application.yml 加载时 ↓ ApplicationContext 已经开始创建 ↓ DataSourceAutoConfiguration 已触发 ↓ 但 Nacos 还没加载

于是就出现了非常经典的错误：

Failed to configure a DataSource

👉问题不在数据库，而在“配置来晚了”

三、Spring Boot 2.4 做了什么改变？

1️⃣ 彻底移除 Bootstrap Context

从Spring Boot 2.4 开始：

• ❌ 移除了 Bootstrap Context
• ✅ 引入了Config Data API

这是一次架构级调整。

四、新模型：Config Data（≥ 2.4）

1️⃣ 新的启动流程

读取 application.yml ↓ 解析 spring.config.import ↓ 加载外部配置（Nacos / Config Server） ↓ 合并为统一的 Environment ↓ 创建 ApplicationContext

👉关键变化只有一句话：

application.yml 本身就参与“外部配置加载”了

2️⃣ 关键配置：spring.config.import

在新版本中，只要在application.yml写：

spring:config:import:nacos:

Spring Boot 就会在配置阶段主动加载 Nacos。

这一步，取代了原来的bootstrap.yml。

五、新旧版本能力对比（核心表格）

六、那 bootstrap.yml 现在是不是“废弃”了？

答案是：没有

真实情况是：

👉不是不能用，而是不再“必须”

七、为什么很多人升级后“感觉规则乱了”？

因为：

• 文件名没变（application.yml 还是那个）
• 行为变了（它现在能引入外部配置）
• 很多文章仍然停留在2.3 之前的认知

👉 于是产生错觉：

“是不是 bootstrap 和 application 没区别了？”

答案是：机制变了，但职责依然不同。

八、新版本仍然会踩坑的 2 个地方（重要）

❌ 1️⃣ 忘记写 spring.config.import

spring:cloud:nacos:config:server-addr:xxx

👉这样是不会加载 Nacos 的

必须有：

spring:config:import:nacos:

⚠️ 2️⃣ 使用 optional:nacos 掩盖问题

spring:config:import:optional:nacos:

错误会被吞掉，排查难度极高。

九、如何选择？

能不迁移就不迁移，
新项目再考虑 config.import。

十、总结

不是 application.yml 变强了，
而是 Spring Boot 的配置加载模型升级了。

Spring Boot 2.4，是配置体系的分水岭。