17370845950

新闻动态

Spring Boot 有哪几种读取配置的方式？

Spring Boot通过application.properties/yml、@Value、@ConfigurationProperties、环境变量、命令行参数等多种方式读取配置，并按优先级生效，其中命令行参数优先级最高，支持多环境Profile管理，推荐使用@ConfigurationProperties处理结构化配置以提升可维护性。

Spring Boot在读取配置方面提供了多种灵活且强大的机制，最常见且基础的包括

application.properties

或

application.yml

文件、通过

@Value

注解直接注入单个属性、以及利用

@ConfigurationProperties

注解将一组相关配置绑定到Java对象上。此外，它还支持从环境变量、命令行参数、JNDI等多种外部源加载配置，并遵循一套严格的优先级规则，确保在不同场景下配置的灵活性和可覆盖性。

Spring Boot在配置管理上的设计，在我看来，简直是神来之笔。它不仅提供了一系列开箱即用的配置方式，更重要的是，它建立了一套清晰的优先级体系，让开发者能够非常灵活地管理应用程序在不同环境下的行为。

解决方案

我们来深入聊聊Spring Boot那些读取配置的“看家本领”。

首先，最基础也是最常用的，无疑是

application.properties

或
application.yml
文件。这是Spring Boot应用程序的默认配置中心。当项目启动时，Spring Boot会自动加载这些文件。我个人更偏爱YAML格式，因为它通过缩进清晰地展现了配置的层次结构，写起来也更直观、更整洁，尤其是在配置项比较多、结构比较复杂的时候，可读性远超传统的

.properties

文件。比如，一个数据库连接配置，在YAML里可能是这样的：

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb
    username: user
    password: password
    driver-class-name: com.mysql.cj.jdbc.Driver

而对应的

.properties

文件则会是扁平的：

spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=user
spring.datasource.password=password
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

这两种文件都支持通过

application-{profile}.yml

或

application-{profile}.properties

来定义特定环境的配置，比如

application-dev.yml

用于开发环境，

application-prod.yml

用于生产环境，通过

spring.profiles.active

属性或环境变量来激活。

接下来是

@Value

注解。这是一种非常直接的方式，用于将单个配置属性注入到Spring管理的Bean的字段或方法参数中。它的语法很简单，通常是

@Value("${some.property.key}")

。

@Component
public class MyService {

    @Value("${app.name}")
    private String appName;

    @Value("${app.version:1.0.0}") // 可以设置默认值
    private String appVersion;

    public void printInfo() {
        System.out.println("App Name: " + appName + ", Version: " + appVersion);
    }
}

@Value

用起来很方便，特别是当你只需要获取少数几个不相关的配置项时。但如果你的配置项很多，而且它们之间有逻辑上的关联，都散落在不同的

@Value

注解中，那代码就会显得有些臃肿和难以维护。这时候，你就需要考虑更高级的武器了。

那就是

@ConfigurationProperties

注解。这是我个人在处理复杂配置时最喜欢的方式。它允许你将一组相关的配置属性绑定到一个POJO（Plain Old Java Object）上，实现类型安全的配置。Spring Boot会自动将配置源中以特定前缀开头的属性映射到POJO的字段上。

@Component
@ConfigurationProperties(prefix = "app.settings")
public class AppSettings {
    private String name;
    private String description;
    private List features; // 支持集合类型

    // Getters and Setters
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getDescription() { return description; }
    public void setDescription(String description) { this.description = description; }
    public List getFeatures() { return features; }
    public void setFeatures(List features) { this.features = features; }
}

然后在

application.yml

中：

app:
  settings:
    name: My Awesome App
    description: A powerful application for everything.
    features:
      - User Management
      - Data Analytics
      - Reporting

在其他组件中，你就可以直接注入

AppSettings

对象来获取所有相关配置，代码会非常清晰和优雅。这种方式不仅提供了类型安全，还支持数据校验（通过

@Validated

），甚至可以很好地支持复杂的嵌套结构，简直是配置管理者的福音。

除了文件和注解，Spring Boot还会从环境变量和命令行参数中读取配置。这两种方式的优先级通常高于文件配置，非常适合在部署时动态调整某些关键参数，而无需修改和重新打包应用程序。例如，

java -jar myapp.jar --server.port=8081

会覆盖

application.properties

中定义的端口。环境变量的命名规则通常是将点号分隔的属性名转换为大写，并用下划线替换点号，比如

SERVER_PORT

对应

server.port

。

最后，对于更高级或动态的场景，Spring Boot的

Environment

抽象和
PropertySource
机制提供了更底层的控制。你可以直接注入

Environment

对象来程序化地获取任何配置属性，或者自定义

PropertySource

来从任意来源加载配置。这通常用于集成一些非标准配置源，或者进行一些复杂的配置处理逻辑。

Spring Boot配置加载的优先级是怎样的？

理解Spring Boot配置的加载优先级是至关重要的，它决定了当同一个属性在不同地方被定义时，哪个值会最终生效。Spring Boot采用了一种非常精细且多层次的“外部化配置”策略，其优先级从高到低大致遵循以下顺序：

命令行参数（Command-line arguments）：这是优先级最高的。当你通过
```
java -jar your-app.jar --server.port=8081
```
这种方式启动应用时，
```
--server.port=8081
```
会覆盖所有其他来源的
```
server.port
```
配置。
SPRING_APPLICATION_JSON
：在环境变量中嵌入的JSON配置，或者作为系统属性。
ServletConfig初始化参数：在
```
web.xml
```
或
```
@ServletComponentScan
```
中定义的参数。
ServletContext初始化参数：同样在
```
web.xml
```
中定义。
JNDI属性：来自
```
java:comp/env
```
。
Java系统属性（System properties）：通过
```
java -Dkey=value
```
设置的属性。
操作系统环境变量（OS environment variables）：例如
```
SERVER_PORT=8081
```
。需要注意的是，Spring Boot会将环境变量名中的下划线转换为点，并将所有字母转换为小写，以匹配属性名。

application-{profile}.properties
或
application-{profile}.yml
：特定于活动profile的配置。例如，如果

spring.profiles.active=dev

，那么

application-dev.yml

或

application-dev.properties

的配置会在这里生效。

application.properties
或
application.yml
：位于当前目录或classpath根目录下的标准配置文件。
@PropertySource
注解：通过
```
@PropertySource
```
注解加载的配置。
默认属性（Default properties）：Spring Boot内部定义的默认值。

这个优先级列表并非一成不变的，有些情况会略有调整，但核心思想是：离应用程序启动和运行环境越近、越动态的配置源，其优先级越高。 这使得我们可以在不修改代码和打包文件的情况下，通过调整外部环境参数来灵活控制应用程序的行为。举个例子，我通常会在

application.yml

中定义开发环境的数据库连接，但在生产环境部署时，我会通过环境变量或者命令行参数来覆盖数据库连接信息，这样既安全又方便。

什么时候应该使用@Value，什么时候使用@ConfigurationProperties？

这是一个非常常见的选择题，也是我在实际开发中经常需要权衡的地方。简单来说，它们各有优势，适用于不同的场景。

使用

@Value

的场景：

获取单个、不相关的配置项：当你的Bean只需要一两个独立的配置值时，比如一个应用的名称、一个固定的API密钥，
```
@Value
```
是最简洁、最直接的选择。
快速原型开发或临时性配置：在项目初期或者某个功能模块需要快速验证时，用
```
@Value
```
可以快速获取配置，减少额外的POJO定义。
需要设置默认值：
```
@Value("${key:defaultValue}")
```
这种语法可以直接在注解中提供默认值，非常方便。
处理Spring表达式语言（SpEL）：
```
@Value
```
支持SpEL，可以实现更复杂的表达式求值，例如
```
@Value("#{systemProperties['java.version']}")
```
。

@Value

的缺点：

缺乏类型安全：它返回的是字符串，你需要手动进行类型转换，容易出错。
代码冗余：如果一个类需要注入很多配置项，每个都用
```
@Value
```
会导致代码非常冗长，且难以阅读。
难以管理：相关的配置项分散在代码各处，不利于统一管理和查找。
不支持复杂结构：无法直接映射嵌套对象或集合。

使用

@ConfigurationProperties

的场景：

获取一组相关、结构化的配置项：这是它的核心优势。当你的配置项具有共同的前缀，并且在逻辑上属于一个整体时，比如数据库连接信息、第三方API客户端配置、自定义业务参数等，
```
@ConfigurationProperties
```
是最佳选择。
实现类型安全的配置：它将配置直接映射到POJO的字段上，Spring Boot会自动完成类型转换，大大减少了运行时错误。
支持复杂的数据结构：POJO可以包含嵌套对象、List、Map等，完美地映射YAML或Properties中的复杂结构。
数据校验：结合
```
@Validated
```
注解和JSR 303/380（Bean Validation）规范，你可以对配置属性进行强大的校验，确保配置值的有效性，比如
```
@Min
```
,
```
@Max
```
,
```
@NotNull
```
等。
利于代码重构和维护：将配置集中到一个POJO中，使得配置的查找、修改和重构变得非常容易。

我的个人建议是：

如果只是偶尔需要一个或两个独立的、简单的配置值，
```
@Value
```
是完全可以的。
但凡是涉及到一组相关联的配置，或者配置项数量超过两三个，并且可能在未来扩展，果断选择
@ConfigurationProperties
。它虽然初期需要定义一个POJO，但从长远来看，它能带来更好的可维护性、类型安全和代码清晰度。在大型项目中，我几乎总是优先考虑
```
@ConfigurationProperties
```
，它能让配置管理变得井井有条。

如何在不同环境中管理Spring Boot配置？

在实际的软件开发和部署中，应用程序往往需要在不同的环境（开发、测试、生产、UAT等）下运行，每个环境可能需要不同的配置，比如数据库连接、日志级别、外部服务地址等。Spring Boot提供了一套非常成熟和灵活的机制来应对这种挑战。

使用Profile（配置文件）：这是Spring Boot管理多环境配置最核心、最常用的方式。你可以在
```
application.yml
```
或
```
application.properties
```
的基础上，创建特定环境的配置文件，例如：
- ```
application-dev.yml
```
  (开发环境)
- ```
application-test.yml
```
  (测试环境)
- ```
application-prod.yml
```
  (生产环境)
这些特定环境的配置文件会覆盖
```
application.yml
```
（或
```
application.properties
```
）中相同名称的属性。要激活某个Profile，你可以在启动应用时通过以下方式指定：
- 命令行参数：
```
java -jar your-app.jar --spring.profiles.active=prod
```
- 环境变量：
```
SPRING_PROFILES_ACTIVE=prod java -jar your-app.jar
```
- 系统属性：
```
java -Dspring.profiles.active=prod -jar your-app.jar
```
- 在
  application.yml
  中设置默认Profile：
```
spring:
  profiles:
    active: dev # 默认激活dev profile
```
  我通常会在
```
application.yml
```
  中放置所有环境通用的配置，然后在
```
application-{profile}.yml
```
  中放置特定环境的差异化配置。这种方式非常直观和高效。
操作系统环境变量和命令行参数：正如前面提到的，环境变量和命令行参数拥有更高的优先级。这对于在容器化部署（如Docker、Kubernetes）场景下管理配置尤为重要。你可以通过容器编排工具（如
```
docker-compose.yml
```
或Kubernetes的
```
Deployment
```
配置）来设置环境变量，从而在运行时动态地注入配置，而无需修改镜像。例如，在Docker中设置数据库URL：
```
environment:
  - SPRING_DATASOURCE_URL=jdbc:mysql://prod-db:3306/prod_db
```
这种方式在生产环境中非常流行，因为它将配置与应用程序代码解耦，提高了部署的灵活性和安全性。
外部化配置服务器（如Spring Cloud Config）：对于微服务架构或大型分布式系统，仅仅依靠文件和环境变量可能不够灵活。Spring Cloud Config提供了一个中心化的配置服务，可以将所有微服务的配置存储在一个Git仓库中，并提供HTTP接口供服务获取。
- 优点：
  - 集中管理：所有服务的配置都集中在一个地方。
  - 版本控制：配置存储在Git中，可以进行版本管理、回滚和审计。
  - 动态刷新：可以在不重启应用的情况下刷新配置。
  - 安全性：支持配置加密。
- 工作原理：Config Server从Git仓库（或其他后端）读取配置，客户端服务（Config Client）在启动时向Config Server请求配置。
虽然引入Config Server会增加一些架构复杂性，但对于管理几十甚至上百个微服务的配置来说，它带来的便利性和可维护性是无与伦比的。我个人在处理大型微服务项目时，几乎总是会考虑引入Spring Cloud Config。
自定义
```
PropertySource
```
：在某些特殊场景下，你可能需要从非标准来源加载配置，比如自定义的数据库表、远程API接口、或者一个特定的文件格式。这时，你可以通过实现
```
PropertySource
```
接口来创建自定义的配置源。这需要一些Spring框架的深入知识，但提供了极大的灵活性。

综合来看，Spring Boot提供了从简单到复杂、从静态到动态的多层次配置管理方案。对于大多数项目，Profile结合环境变量已经足够应对；而对于大型分布式系统，引入Spring Cloud Config则能带来更高的效率和可维护性。选择哪种方式，最终还是取决于项目的规模、复杂度和团队的技术栈偏好。

17370845950

Spring Boot配置加载的优先级是怎样的？

什么时候应该使用@Value，什么时候使用@ConfigurationProperties？

如何在不同环境中管理Spring Boot配置？

关于我们

服务项目

广告推广

案例欣赏