当项目从单体架构演进到微服务架构之后，配置文件的管理方式往往成为第一个暴露出来的问题。每个服务都有自己的 application.yml，修改一个数据库连接地址可能需要改动十几个工程，重新打包、重新部署，整个过程耗时且容易出错。Spring Cloud Config 提供了一套集中式的配置管理方案，它把所有配置文件统一存放在 Git 仓库中，服务启动时从配置中心拉取配置，配合动态刷新机制还能做到不重启服务就更新配置。本文将完整演示 Spring Boot 整合 Spring Cloud Config 的全过程。
一、Spring Cloud Config 的核心原理
Spring Cloud Config 采用的是典型的服务端与客户端架构。服务端也就是 Config Server，它本身并不存储配置，而是作为一个中间层，从后端存储（通常是 Git 仓库，也可以是 SVN、本地文件系统或数据库）中读取配置文件，然后提供给客户端访问。客户端也就是 Config Client，嵌入在各个业务微服务中，在服务启动的 Bootstrap 阶段向 Config Server 发起请求，把远程配置拉取到本地并加载到 Spring 环境中。
配置文件在 Git 仓库中的命名遵循一定的约定，格式为{应用名}-{profile}.yml，例如order-service-dev.yml、order-service-prod.yml。Config Server 会根据客户端传入的应用名和激活的 profile，自动拼接出对应的文件路径去 Git 仓库查找。查找顺序也有讲究，不带 profile 的文件会先加载，带 profile 的文件后加载并覆盖前者，这样公共配置和环境差异化配置可以分开维护。
需要特别注意的是，从 Spring Boot 2.4 版本开始，默认禁用了 bootstrap 上下文，如果还按照老版本的方式配置，客户端将无法连接配置中心。解决方案有两种：一是引入spring-cloud-starter-bootstrap依赖，恢复传统行为；二是改用新的spring.config.import方式。这一点是整合过程中最常见的坑，后面会详细说明。
二、搭建 Config Server 服务端
首先创建一个独立的 Maven 工程，引入 Config Server 的依赖。完整的 pom.xml 关键依赖如下：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<lt;!-- Spring Boot 2.4 之后如需传统 bootstrap 方式，客户端要加此依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>然后在启动类上添加@EnableConfigServer注解，开启配置中心服务：
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}接着编写服务端的配置文件 application.yml，指定 Git 仓库地址和搜索路径：
server:
port: 8888
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://github.com/my-project/config-repo.git
search-paths: '{application}'
username: your-username
password: your-token
default-label: main这里的search-paths支持占位符，表示按照应用名分目录存放配置文件，仓库结构会更加清晰。如果使用私有仓库，需要配置用户名和访问令牌；如果使用 Gitee 或自建 GitLab，把 uri 换成对应地址即可。启动后可以访问http://127.0.0.1:8888/order-service/dev来验证，返回 JSON 格式的配置内容说明服务端搭建成功。
三、客户端接入与动态刷新
业务服务接入配置中心需要引入spring-cloud-starter-config依赖，并创建 bootstrap.yml 文件指定配置中心地址：
spring:
application:
name: order-service
cloud:
config:
uri: http://127.0.0.1:8888
profile: dev
label: main如果使用 Spring Boot 2.4 及以上版本且不想引入 bootstrap 依赖，也可以在 application.yml 中使用导入方式：
spring:
config:
import: optional:configserver:http://127.0.0.1:8888配置好之后，在业务类中就可以通过@Value注解注入远程配置的属性值，用法与本地配置完全一致。但此时存在一个问题：Git 上的配置修改后，客户端不会自动感知，必须重启服务。要实现动态刷新，需要在对应的 Bean 上添加@RefreshScope注解：
@RestController
@RefreshScope
public class ConfigController {
@Value("${order.timeout:3000}")
private Integer timeout;
@GetMapping("/timeout")
public Integer getTimeout() {
return timeout;
}
}同时在客户端暴露 actuator 的 refresh 端点，配置management.endpoints.web.exposure.include=refresh。之后每当 Git 上的配置变更，只需向客户端发送一次 POST 请求到/actuator/refresh，Bean 就会重新加载新的配置值，无需重启进程。如果服务实例很多，逐个调用显然不现实，这时可以引入 Spring Cloud Bus 配合消息中间件（如 RabbitMQ），配合 Git 的 Webhook 回调，实现一次推送、全部实例自动刷新的广播效果。
四、生产环境的高可用与安全考虑
单独部署一台 Config Server 存在单点故障风险，一旦配置中心宕机，所有依赖它的服务都无法启动。生产环境通常的做法是把 Config Server 也注册到 Eureka 或 Nacos 注册中心，部署多个实例，客户端通过服务名而非具体地址访问，配合负载均衡自动容灾。此外，客户端还可以配置spring.cloud.config.fail-fast=true和重试参数，当配置中心暂时不可用时进行多次重试，避免服务因瞬时网络抖动而启动失败。
安全性方面，配置中心往往保存着数据库密码、密钥等敏感信息，明文存放在 Git 仓库中风险较高。一方面可以为 Config Server 开启 Spring Security 认证，客户端配置用户名密码后才能拉取配置；另一方面可以对敏感字段使用 JCE 加密，在 Git 中只存放密文，配置加解密密钥encrypt.key后，使用{cipher}前缀标注加密值，Config Server 会在返回配置时自动解密。
最后需要提醒的是，Spring Cloud Config 适合已经有成熟 Git 体系、对配置变更审计有要求的团队。如果项目对实时性和管理界面要求更高，也可以考虑 Nacos 作为替代方案，它把注册中心和配置中心合二为一，还提供了控制台和灰度发布能力。技术选型没有绝对优劣，结合团队现状选择合适的方案才是关键。
Spring Boot配置中心Spring Cloud Config修改时间：2026-08-31 00:42:47