1. 认识Spring Boot的配置双雄

第一次接触Spring Boot时，很多人都会被两个相似的配置文件搞懵——bootstrap.yml和application.yml。它们就像一对双胞胎兄弟，看似相同却各司其职。记得我刚工作时，就因为用错了配置文件，导致项目连不上配置中心，排查了半天才发现问题所在。

这两个文件都是Spring Boot支持的配置文件格式（也支持.properties格式），但它们的加载时机和作用范围完全不同。简单来说：

• bootstrap.yml是配置系统的"先锋官"，负责最基础的引导配置
• application.yml则是"主力军"，承载应用的主要配置

举个生活中的例子：就像装修房子，bootstrap.yml负责联系装修公司、确定施工方案（基础配置），而application.yml则决定墙面刷什么颜色、地板铺什么材质（应用具体配置）。

2. 为什么需要两个配置文件？

2.1 配置加载的先后顺序

Spring Boot启动时，会先创建一个Bootstrap Context（引导上下文），这时就会加载bootstrap.yml中的配置。之后才会创建我们熟悉的Application Context（应用上下文），加载application.yml。

这种设计源于一个核心需求：有些配置必须在应用启动的最早期就准备好。比如：

• 连接配置中心（如Nacos）的地址和认证信息
• 应用名称（用于服务注册）
• 加解密相关的密钥配置

如果这些配置放在application.yml中，等加载时已经太晚了——应用连配置中心都连不上，怎么获取其他配置呢？

2.2 典型应用场景对比

通过一个表格对比它们的典型使用场景：

3. 深度解析加载机制

3.1 上下文层次结构

Spring Cloud应用启动时，会建立父子上下文关系：

Bootstrap Context (父) └── Application Context (子)

这种设计带来几个关键特性：

1. 父上下文配置优先加载
2. 子上下文可以覆盖父上下文的配置（除非特别设置）
3. 环境变量(Environment)会被共享

3.2 属性覆盖规则

默认情况下，bootstrap.yml中的属性具有更高优先级，且不能被application.yml覆盖。这是为了防止关键配置被意外修改。但可以通过以下方式调整：

# 在bootstrap.yml中允许覆盖 spring: cloud: config: allowOverride: true overrideNone: true # 允许任何本地配置覆盖 overrideSystemProperties: false # 仅系统属性可覆盖

3.3 自定义加载逻辑

如果需要深度定制配置加载过程，可以实现PropertySourceLocator接口：

@Configuration public class CustomPropertySourceLocator implements PropertySourceLocator { @Override public PropertySource<?> locate(Environment env) { Map<String, Object> customConfig = // 从自定义来源读取配置 return new MapPropertySource("customSource", customConfig); } }

然后在META-INF/spring.factories中注册：

org.springframework.cloud.bootstrap.BootstrapConfiguration=com.example.CustomPropertySourceLocator

4. 实战配置指南

4.1 基础配置示例

典型的bootstrap.yml配置（以Nacos为例）：

spring: application: name: order-service cloud: nacos: config: server-addr: 127.0.0.1:8848 namespace: dev file-extension: yaml shared-configs: # 共享配置 ->server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/order_db username: root password: 123456 custom: max-retry: 3 timeout: 5000

4.2 多环境配置策略

建议采用以下目录结构：

src/main/resources/ ├── bootstrap.yml # 基础引导配置 ├── application.yml # 默认应用配置 ├── application-dev.yml # 开发环境 └── application-prod.yml # 生产环境

在bootstrap.yml中激活环境：

spring: profiles: active: @activatedProperties@ # 配合maven过滤

4.3 常见问题解决

问题1：bootstrap.yml不生效解决方案：

1. 确认已添加依赖：

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bootstrap</artifactId> </dependency>

2. 检查文件名拼写是否正确
3. 确认文件放在resources目录下

问题2：配置加载顺序不符合预期可以通过调试模式查看加载过程：

--debug

或在代码中打印：

@SpringBootApplication public class MyApp { public static void main(String[] args) { ConfigurableApplicationContext context = SpringApplication.run(MyApp.class, args); System.out.println("Property sources: " + context.getEnvironment().getPropertySources()); } }

5. 高级应用技巧

5.1 动态配置刷新

结合@RefreshScope实现配置热更新：

@RestController @RefreshScope public class ConfigController { @Value("${custom.timeout}") private Integer timeout; @GetMapping("/timeout") public Integer getTimeout() { return timeout; } }

5.2 配置加解密

1. 首先在bootstrap.yml中配置加密密钥：

encrypt: key: my-secret-key

2. 使用加密后的值：

spring: datasource: password: '{cipher}密文'

3. 通过/encrypt端点加密数据：

curl localhost:8080/encrypt -d "plaintext"

5.3 自定义配置源

实现从数据库读取配置：

public class JdbcPropertySourceLocator implements PropertySourceLocator { @Autowired private DataSource dataSource; @Override public PropertySource<?> locate(Environment env) { Map<String, Object> properties = new HashMap<>(); try (Connection conn = dataSource.getConnection()) { // 查询配置数据 ResultSet rs = conn.createStatement().executeQuery("SELECT key, value FROM app_config"); while (rs.next()) { properties.put(rs.getString("key"), rs.getString("value")); } } catch (SQLException e) { throw new RuntimeException("加载数据库配置失败", e); } return new MapPropertySource("jdbcConfig", properties); } }

6. 最佳实践与避坑指南

在实际项目中，我总结了以下经验：

1. 最小化原则：bootstrap.yml只放必须的配置，通常不超过20行
2. 安全配置：敏感信息如密码、密钥只放在bootstrap.yml
3. 环境隔离：不同环境使用不同的配置中心namespace
4. 版本控制：application.yml可以纳入版本控制，bootstrap.yml建议通过配置中心管理

常见陷阱：

• 在bootstrap.yml中使用Spring Boot特有的配置（如server.port）
• 在application.yml中配置本应属于bootstrap的内容（如配置中心地址）
• 过度使用属性覆盖，导致配置难以追踪

对于微服务架构，推荐采用这样的配置分层：

1. 基础设施配置（bootstrap.yml）
2. 应用通用配置（application.yml）
3. 环境特定配置（application-{env}.yml）
4. 本地开发配置（本地覆盖）

记得有次生产环境事故，就是因为有人把Redis配置放在了application.yml，而配置中心又覆盖了这部分配置，导致连不上生产环境的Redis。后来我们制定了严格的配置规范，类似问题再没发生过。