在单体应用向微服务拆分的过程中，配置管理往往是最先暴露问题的环节。每个服务都自带一份application.yml，数据库地址、消息队列参数、第三方密钥等内容散落各处，一旦环境从开发切到测试，再切到生产，就需要逐个人工核对甚至修改文件。Spring Boot生态中的Config组件提供了一种集中式配置思路：把配置统一存放到Git仓库，由服务端负责拉取并对外提供接口，各业务服务作为客户端按需获取。下面结合代码逐步完成整合。
一、先理解Config的集中配置模型
Config中心的核心角色有两个：服务端和客户端。服务端通常是一个独立的Spring Boot应用，它启动后会连接指定的Git仓库，并把仓库中的配置文件解析成HTTP接口。客户端则是普通的业务服务，在启动时通过配置的地址向服务端发起请求，拉取与自己相关的配置项并与本地配置合并。相比传统方式，这样做最直接的好处是配置修改不需要重新打包应用，只要更新仓库并触发刷新即可。
从实现角度看，Config并没有改变Spring Boot原有的配置优先级，而是在Environment加载阶段加入了一个远程数据源。客户端通过bootstrap上下文在应用主配置之前就读取到远程配置，因此数据库连接这类关键信息也能来自配置中心。架构上常见的部署方式是配置中心服务端单独跑在一台机器或容器中，所有客户端在启动脚本里只写服务端地址和自身应用名，不再保存密码等敏感内容。
二、搭建Config服务端
新建一个Spring Boot工程，在pom.xml中加入Config服务端依赖。这个依赖会引入配置中心所需的控制器和仓库解析逻辑。比如使用Maven时，依赖如下：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
然后在启动类上添加@EnableConfigServer注解，开启服务端能力。这个注解会注册一组处理配置读取请求的端点，常见的请求路径包含应用名、环境名和分支名。接下来在application.yml中配置Git仓库地址，Config服务端会在启动后从该仓库拉取配置文件。
spring:
cloud:
config:
server:
git:
uri: https://github.com/yourname/config-repo.git
username: yourname
password: yourpassword
default-label: main
server:
port: 8888
仓库中的文件命名有约定的格式，通常为{application}-{profile}.yml或{application}-{profile}.properties。例如订单服务在开发环境的配置文件名为order-service-dev.yml。Config服务端会根据客户端请求参数拼出文件名，并在仓库中找到对应文件返回。启动服务端后可访问http://localhost:8888/order-service/dev/main验证是否返回配置内容。
三、客户端接入并读取远程配置
客户端同样需要引入Config客户端依赖。与普通Spring Boot应用的差异在于，客户端需要提前告诉框架配置中心服务端的地址以及自己要获取哪个应用配置。这个信息必须放在bootstrap.yml里，因为bootstrap上下文先于主配置加载。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
spring:
application:
name: order-service
cloud:
config:
uri: http://localhost:8888
profile: dev
label: main
客户端启动时会请求配置中心，并根据上述参数拉取order-service-dev.yml。拉取到的配置会合并到Environment中，因此本地只需要保留极少量的配置，例如服务端口也可以放在远程仓库。为了验证远程配置是否生效，可以在控制器中通过@Value注入一个自定义属性。
@RestController
public class TestController {
@Value("${message.hello}")
private String hello;
@GetMapping("/hello")
public String hello() {
return hello;
}
}
远程文件中的message.hello值会被注入，访问/hello即可看到结果。这个例子说明了配置中心已经接管了业务配置。
四、配置动态刷新与常见注意点
把配置集中之后，一个更实际的需求是修改仓库中的配置后能否不重启应用就生效。Spring Boot生态里通常配合Actuator暴露刷新端点，同时在需要刷新的Bean上标注@RefreshScope。当客户端收到配置变更通知时，框架会重新创建这些Bean，重新绑定配置值。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
management:
endpoints:
web:
exposure:
include: refresh
在控制器或服务类上添加@RefreshScope后，当Git仓库中的配置更新，向客户端发送一次POST请求到/actuator/refresh，就能让新值生效。手动触发适合测试阶段，生产环境一般会接入消息总线或定时任务批量刷新。需要注意的是，加密配置和数据库连接池这类底层参数刷新时的行为可能不同，建议将经常变化的业务开关、限流阈值等放在可刷新范围内，而基础设施参数尽量通过重启保证一致性。
另一个容易忽略的问题是多环境冲突。客户端本地如果保留了同名配置，Config远程配置默认不覆盖本地值，需要显式设置覆盖策略。此时可以调整Spring Cloud的配置覆盖规则，避免线上环境读取到本地残留值。建议正式上线前清理本地bootstrap中的无关配置，只保留微服务名称和配置中心地址，把环境差异完全交给仓库管理。
Spring Boot配置中心Spring Cloud Config修改时间：2026-09-19 19:39:41