面经策

Spring Boot 中 application.properties 和 application.yml 的区别是什么？ ​

  • 标签：Spring Boot、后端

🏛 业务架构师 ​

application.properties 和 application.yml 的功能完全等价——都是 Spring Boot 外部化配置的载体，加载优先级相同（同目录同时存在时 properties 优先），区别在表达形式：

  • properties：扁平的 key=value，无层级，重复前缀冗长（spring.datasource.url=...、spring.datasource.username=...）；
  • yml：缩进树状结构，同模块配置聚拢，支持列表（- item）、多文档块（--- 分隔，可按 Profile 分段）：
yaml
spring:
  datasource:
    url: jdbc:mysql://...
    username: app
  profiles: prod   # 一个文件管理多环境
---
spring:
  config:
    activate:
      on-profile: dev

架构师视角，我的团队规范是统一 yml，理由是治理性的：

  1. 可读性和归属感：树状结构天然呈现配置的模块归属，review 时改动影响域一目了然；
  2. 多 Profile 分段减少文件数量，环境骨架一处可查；
  3. 成本可控的坑要培训：yml 靠缩进定层级（Tab 不允许）、冒号后必须空格、"密码 123456 会被解析成数字/科学计数法"这类类型推断坑——统一格式 + Code Review 检查项，比混合使用两种格式更省心。

一句话：语义无差别，选择是团队约定问题；一致性和培训到位，比格式本身重要得多。

🏗 系统架构师 ​

等价与差异：

  • 优先级等价：同一目录下 application.properties 优先于 application.yml——位置决定优先级，格式本身不加分；
  • yml：层级缩进表达结构，同前缀配置聚合可读性好；支持多文档块（--- 按 profile 分段）；只认空格缩进；重复 key 会静默覆盖；支持锚点复用；
  • properties：扁平 key-value，无层级噪音，解析最简单，工具兼容最稳。

我的实践取舍：团队统一一种（国内主流 yml），禁止混用——两种并存时覆盖关系难推理，是配置事故温床。yml 多文档块按 profile 分段很实用。

再补两个生产细节：

  1. yml 有 YAML 1.1 的历史坑：on/off/yes/no 会被解析成布尔，版本号类值必须加引号；
  2. 生产敏感配置不落文件——走环境变量、K8s Secret、配置中心注入，配置文件里只留非敏感默认值。

💻 全栈开发专家 ​

同一种外部化配置的两种格式，Boot 都支持。差异：

  • 语法：properties 扁平 key=value 无层级；yml 缩进表达层级，: 后必须空格，禁止 Tab（手滑插 Tab 就启动报错，新手最常见事故）
  • 可读性：配置一多 yml 优势明显：
yaml
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/order
    username: root
    hikari:
      maximum-pool-size: 20
  • 优先级：同位置下 properties > yml（后加载覆盖）
  • yml 的坑：缩进错一位静默变成另一个 key，配置"看着对但不生效"多半是它；on/off/yes 这类值会被解析成布尔，要加引号；多 profile 用 --- 分隔

团队实践：统一 yml、禁止混用——两种同名文件并存时优先级坑多；层级超过三层说明该拆 profile 或拆文件（application-redis.yml + spring.profiles.include）。

IDE 联动：properties 和 yml 都吃 spring-configuration-metadata，自定义配置配 @ConfigurationProperties + spring-boot-configuration-processor 生成元数据，补全和校验都有了——这步很多人漏，配置写错只能等启动报错。