spring boot 核心配置文件是什么？

spring Boot 的核心配置文件是 application.properties 和 application.yml，前者使用键值对，后者采用 YAML 格式，通过缩进表示层级，更易读且适合复杂配置；YAML 优先级高于 properties，二者可共存但建议只用一种；通过 Profile 实现多环境管理，如 application-dev.yml 等，并可通过命令行、环境变量等方式激活；配置加载顺序从高到低依次为：命令行参数、系统属性、环境变量、Profile 配置、默认配置文件等，实现灵活的外部化配置。

spring boot 的核心配置文件，说白了，就是

application.properties

或者

application.yml

。它们是 Spring Boot 应用启动时，自动加载并解析的默认配置文件。你所有的应用级配置，比如端口号、数据库连接、日志级别，甚至是你自己定义的业务参数，通常都会放在这里。

解决方案

在我看来，

application.properties

和

application.yml

它们不仅仅是文件，更是 Spring Boot 强大“约定优于配置”理念的直接体现。Spring Boot 启动时，会按照一套既定的顺序去查找这些文件，并把里面的配置项绑定到对应的 Bean 或者环境中去。

application.properties

采用的是传统的键值对（key=value）形式，就像这样：

server.port=8080 spring.datasource.url=jdbc:mysql://localhost:3306/mydb logging.level.root=INFO

这种格式直观，对于简单的配置来说非常友好。但如果你有很多层级的配置，或者想表达更复杂的结构，它可能会显得有些冗长，需要用点分隔符来模拟层级。

而

application.yml

（或

application.yaml

）则采用了 YAML 格式，这是一种更现代、更结构化的方式。它通过缩进和冒号来表示层级关系，读起来更清晰，尤其是在配置项很多，层级很深的时候，优势就体现出来了：

server:   port: 8080 spring:   datasource:     url: jdbc:mysql://localhost:3306/mydb logging:   level:     root: INFO

我个人更倾向于使用

application.yml

，因为它在视觉上更整洁，也更容易理解配置项之间的父子关系。当然，具体用哪种，很多时候也取决于团队的习惯和项目的历史包袱。Spring Boot 默认会优先加载 YAML 格式的配置文件，如果两者都存在，YAML 会覆盖 properties 文件中同名的配置项。所以，一般我们只会选择其中一种来用。

它们之所以“核心”，是因为它们提供了应用运行所需的基础环境和行为设定。没有它们，或者说没有正确配置它们，你的 Spring Boot 应用可能根本就跑不起来，或者跑起来也无法正常工作。它们是应用与外部世界（数据库、消息队列、第三方服务等）交互的桥梁，也是你调整应用内部行为（比如日志输出、线程池大小）的控制中心。

Spring Boot 配置文件有哪些常用格式，它们之间有什么区别？

Spring Boot 配置文件最常用的格式就是

.properties

和

.yml

(或

.yaml

)。它们的主要区别体现在语法结构、可读性和表达复杂配置的能力上。

.properties

文件是 Java 世界里很传统的配置文件格式，以键值对的形式存在，每个配置项一行。比如

my.app.name=MyApplication

。它的优点是简单直接，兼容性好，很多旧系统或工具可能只认这种格式。但缺点也明显，当配置项层级很深时，你需要不断重复前缀，比如

spring.datasource.url

、

spring.datasource.username

，看起来会比较啰嗦，而且难以一眼看出配置的整体结构。

而

.yml

(YAML ain’t Markup Language) 格式则是一种更现代、更人性化的数据序列化格式。它通过缩进表示层级，用冒号分隔键值。例如：

my:   app:     name: MyApplication

这种格式的优势在于其清晰的层级结构和更好的可读性，尤其是在处理复杂的嵌套配置时，YAML 的优势非常明显。它避免了键名重复，通过缩进就能直观地看到配置项之间的关系。此外，YAML 还支持列表（数组）的表示，这在处理集合类型的配置时非常方便，比如：

servers:   - host: server1.example.com     port: 8080   - host: server2.example.com     port: 9090

相比之下，

.properties

文件要表示列表就得用索引，比如

servers[0].host=server1.example.com

，相对不那么优雅。

在实际项目中，我发现越来越多的团队倾向于使用 YAML，因为它能让配置变得更“干净”，更容易维护。不过，Spring Boot 对这两种格式都提供了原生支持，你可以根据团队习惯或者个人偏好自由选择。如果一个项目中同时存在

application.properties

和

application.yml

，Spring Boot 会优先加载 YAML 文件，并且 YAML 文件中的同名配置会覆盖 properties 文件中的值。所以，为了避免不必要的混淆，通常建议在一个项目中只使用其中一种格式作为主要的配置文件。

如何实现 Spring Boot 配置文件的多环境管理？

多环境管理是 Spring Boot 配置的另一个亮点，它能让你轻松地在开发、测试、生产等不同环境中切换配置，而无需修改代码。这极大地提升了开发效率和部署的灵活性。Spring Boot 实现多环境管理的核心机制是“Profile”（配置文件）。

基本思路是为每个环境创建独立的配置文件。例如：

• application.properties

  或

  application.yml

  ：作为所有环境的通用配置，或者作为默认配置。

• application-dev.properties

  或

  application-dev.yml

  ：开发环境特有的配置。

• application-test.properties

  或

  application-test.yml

  ：测试环境特有的配置。

• application-prod.properties

  或

  application-prod.yml

  ：生产环境特有的配置。

当 Spring Boot 启动时，如果你激活了某个 Profile，比如

dev

，那么

application-dev.properties

（或

application-dev.yml

）中的配置就会被加载，并且会覆盖

application.properties

（或

application.yml

）中同名的配置项。那些在

application-dev

中没有定义的配置，则会继续使用

application

文件中的默认值。这种层层覆盖的机制非常灵活。

激活 Profile 的方式有很多种，最常见的几种：

1. 通过命令行参数： 这是最直接的方式，特别适合在部署时指定。

   java -jar your-app.jar --spring.profiles.active=dev

   或者同时激活多个 Profile：

   java -jar your-app.jar --spring.profiles.active=dev,mysql

2. 通过系统属性： 在启动 jvm 时设置。

   java -Dspring.profiles.active=test -jar your-app.jar

3. 在

   application.properties

   或

   application.yml

   中指定：

   # application.properties spring.profiles.active=dev

   或者

   # application.yml spring:   profiles:     active: dev

   这种方式通常用于本地开发环境，或者作为默认的 Fallback Profile。不过，在生产环境，我更倾向于通过命令行或环境变量来激活，因为这样在部署时可以更灵活地切换，避免了修改代码或打包。

4. 通过环境变量：

   export SPRING_PROFILES_ACTIVE=prod java -jar your-app.jar

   这是在容器化部署（如 docker、kubernetes）中最常用的方式，因为它能很好地实现配置与代码的分离。

我个人觉得，多环境管理是 Spring Boot 最实用、最“接地气”的功能之一。它解决了我们在不同部署阶段，需要频繁修改配置的痛点。尤其是在微服务架构下，每个服务都可能部署在不同的环境中，这种机制让配置管理变得异常简单和健壮。

除了默认配置，Spring Boot 还能从哪些地方加载配置？

Spring Boot 的配置加载机制远比你想象的要强大和灵活。它不仅仅局限于

application.properties

或

application.yml

，而是有一套非常完善的“外部化配置”体系。这意味着你的配置可以来自很多不同的地方，并且它们之间还有严格的优先级顺序。这套机制保证了在不同场景下，配置的灵活性和可覆盖性。

Spring Boot 默认的配置加载顺序大概有以下几个关键层级（从高到低，高优先级会覆盖低优先级）：

1. 命令行参数： 这是优先级最高的。任何以

   --

   开头的参数都会被转换为配置属性。例如

   --server.port=9000

   会覆盖配置文件中的

   server.port

   。这在快速测试或临时调整时非常有用。

2. Java 系统属性（

   System.properties

   ）： 通过

   java -Dkey=value

   形式设置的属性。比如

   java -Dserver.port=8081 -jar your-app.jar

   。它的优先级仅次于命令行参数。

3. 操作系统环境变量： Spring Boot 会将操作系统环境变量转换为配置属性。例如，

   SERVER_PORT=8082

   环境变量会被映射为

   server.port

   。这种方式在容器化部署中非常常见，因为容器环境通常通过环境变量来传递配置。需要注意的是，环境变量名通常是大写，并用下划线代替点，且可以加

   SPRING_APPLICATION_JSON

   或

   SPRING_CONFIG_LOCATION

   等前缀。

4. RandomValuePropertySource

   ： 这个比较特殊，它用于生成随机值，比如

   my.secret=${random.value}

   。它的优先级比较靠前，确保随机值能被其他配置引用。

5. 特定 Profile 的应用配置（

   application-{profile}.properties

   或

   application-{profile}.yml

   ）： 当激活了某个 Profile 时，比如

   dev

   ，那么

   application-dev.properties

   中的配置会在这里被加载。

6. 应用默认配置（

   application.properties

   或

   application.yml

   ）： 这是我们最常用的默认配置文件，优先级相对较低，可以被其他高优先级的配置覆盖。

7. @PropertySource

   注解加载的配置： 你可以在你的

   @Configuration

   类上使用

   @PropertySource

   注解来指定额外的配置文件。这种方式通常用于加载非 Spring Boot 默认命名规则的配置文件。

8. SpringApplication.setDefaultProperties： 这是通过编程方式设置的默认属性，优先级最低。

这种层层覆盖的机制，我认为是 Spring Boot 外部化配置的精髓。它允许你从最外部（命令行、环境变量）到最内部（代码默认值）逐级定制配置，同时保持了清晰的优先级。在实际开发中，我们经常会利用这种特性，比如本地开发时用

application-dev.yml

，测试环境通过环境变量注入数据库连接，生产环境则可能通过配置中心（如 spring cloud Config）来统一管理和分发配置。这种设计哲学，极大地提升了应用的可部署性和可维护性。