先给一个结论：SpringBoot启动时，配置读取发生在Bean创建之前，这是确保依赖配置的Bean能正确初始化的前提。加入Nacos或SpringCloudConfig后，流程会变成这样：先通过bootstrap.yml获取配置中心地址（避免循环依赖），再拉取远程配置合并到环境变量（Environment），最后创建Bean。Nacos简化了架构（内置配置管理），而SpringCloudConfig需要独立Git+ConfigServer。两者都通过bootstrap阶段（类似BIOS）引导配置加载，核心思想是先定位配置源，再构建应用上下文。这一机制是Sentinel、Seata等框架动态配置的基础，后续可以结合@RefreshScope理解动态刷新原理。
这一节专门解决你刚才卡住的核心：
Spring Boot到底什么时候读取配置？Nacos Config、Spring Cloud Config到底插入在哪一步？
现在不用管Config的代码，先把启动流程建立起来。
一、普通 Spring Boot 启动流程
先看你最熟悉的情况。
一个普通项目：
product-service
src/main/resources
application.yml
启动：
@SpringBootApplication
public class ProductApplication {
public static void main(String[] args){
SpringApplication.run(
ProductApplication.class,
args
);
}
}
整体流程
画成：
JVM启动
|
↓
main方法执行
|
↓
SpringApplication.run()
|
↓
读取 application.yml
|
↓
创建 Spring 容器
|
↓
扫描 Bean
|
↓
创建 Controller/Service/Mapper
|
↓
启动 Tomcat
|
↓
服务运行
重点：
配置读取发生在哪里？
非常早。
在：
创建Bean之前
为什么？
因为创建Bean可能需要配置。
例如：
你的代码：
@Service
public class UserService {
@Value("${jwt.secret}")
private String secret;
}
Spring创建UserService的时候：
必须知道：
jwt: secret: abc123
在哪里。
所以：
先读配置。
再创建对象。
二、现在加入 Nacos Config
之前的AIWear其实已经接触过类似思想。
以前：
服务 | | application.yml
现在：
服务 | | Nacos | | 配置
启动流程变：
JVM启动 | ↓ main方法 | ↓ 读取基础配置 | ↓ 连接Nacos | ↓ 拉取远程配置 | ↓ 合并配置 | ↓ 创建Spring Bean | ↓ 启动服务
注意：
这里有一个关键：
连接Nacos需要地址。
例如：
spring:
cloud:
nacos:
config:
server-addr: localhost:8848
这个配置必须提前知道。
所以：
它不能来自Nacos。
否则：
我要去Nacos拿配置 ↓ 但是不知道Nacos在哪里 ↓ 死循环
所以：
一定存在：
本地启动配置
比如：
bootstrap.yml
里面：
Nacos地址
三、Spring Cloud Config流程
现在换成：
Git + Config Server。
架构：
Git
|
|
↓
Config Server
|
|
↓
product-service
启动：
product-service启动
|
↓
读取 bootstrap.yml
|
↓
知道 Config Server地址
|
↓
访问 Config Server
|
↓
Config Server访问Git
|
↓
返回配置
|
↓
创建Spring Bean
|
↓
启动服务
所以：
bootstrap.yml的角色：
不是存业务配置。
而是：
告诉Spring：配置在哪里。
四、为什么叫 bootstrap？
bootstrap：
英文：启动、引导。
它的意思：
在Spring正式启动之前，引导Spring完成准备工作。
类似电脑：
开机：
第一阶段：BIOS启动。
第二阶段：Windows启动。
BIOS不是你的日常系统。
但是没有BIOS：
Windows启动不了。
bootstrap类似：BIOS。
五、Spring Boot启动层级
我们画一个更细的。
JVM
|
↓
SpringApplication
|
↓
Environment准备阶段
|
↓
读取配置文件
|
-----------------
| |
bootstrap.yml application.yml
|
↓
Config/Nacos配置
|
↓
创建ApplicationContext
|
↓
创建Bean
|
↓
Tomcat启动
这里：
Environment是什么？
简单理解：Spring保存配置的地方。
比如：
你的配置：
server: port:8080 jwt: secret:abc
最终都会进入：
Environment
里面。
然后：
@Value @ConfigurationProperties
都是从Environment拿。
六、Nacos Config和Spring Cloud Config插入位置
对比：
Spring Cloud Config
启动 ↓ bootstrap.yml ↓ Config Server ↓ Git ↓ Environment ↓ Bean
Nacos Config
启动 ↓ bootstrap/application配置 ↓ Nacos Server ↓ Environment ↓ Bean
本质：
一样。
区别：
配置存哪里。
七、为什么你感觉Nacos简单？
因为Nacos把很多事情合并了。
例如：
Spring Cloud Config：
Git + Config Server + Config Client
三个东西。
Nacos：
Nacos Server 全部包含
所以：
你之前学Nacos配置中心：
其实已经理解80%。
现在只是补充：
Spring Cloud原生方案。
八、这个知识为什么重要？
因为以后学：
Sentinel
你会看到：
应用启动 ↓ 加载规则 ↓ 创建保护组件 ↓ 运行
也是启动生命周期。
Seata
也是：
服务启动 ↓ 连接TC ↓ 注册RM ↓ 参与事务
SkyWalking
也是：
JVM启动 ↓ Agent加载 ↓ 增强字节码 ↓ 监控运行
所以：
Spring Boot启动流程是所有框架的基础。
九、你现在应该记住一个简化版
不用背源码。
记：
Spring Boot启动： 1. 找配置 2. 创建环境 3. 创建容器 4. 创建Bean 5. 启动服务 配置中心： 插在第1步和第2步之间。
对应：
普通：application.yml Config：bootstrap → Config Server → Git Nacos：bootstrap/application → Nacos
到这里，Config的核心思想已经理解。
下一步可以进入 Spring Cloud Config动态刷新，也就是：
修改配置以后，为什么服务不用重新打包？Spring是怎么重新加载Bean的？
这个会和你之前学的 Nacos @RefreshScope 联系起来。
