application.yml 和 application.properties 如何选择

比较 YAML 与 Properties 的适用场景、维护成本和迁移注意事项。

撰写与维护： ErickPang · 更新于：

比较 Spring Boot 中 YAML 与 Properties 的可读性、维护成本、迁移风险和团队协作场景。

选择 YAML 的场景

当项目配置层级较深、需要维护多个环境、包含 datasource、management、security、logging 等多个分组时，application.yml 通常更容易阅读。层级结构能让相关配置聚在一起，适合大型项目和团队协作。

YAML 的风险是缩进敏感。团队需要统一两个空格或四个空格的风格，代码评审时也要检查新增配置是否放在正确层级。配合 IntelliJ IDEA 的补全和格式提示，可以明显降低这类错误。

  • 配置分组多，层级关系明显
  • 多环境配置需要保持相同结构
  • 团队希望通过层级结构提升可读性
  • 需要维护列表、Map 或复杂嵌套配置

选择 Properties 的场景

application.properties 更直接，适合配置量较少、已有项目保持兼容、或者团队已经有大量 key=value 文档和脚本的场景。它也更容易和命令行参数、环境变量说明对应起来。

Properties 的问题是文件变长后不容易看出层级关系。同一个前缀的配置可能分散在不同位置，重复 key 和过期 key 更难发现。此时补全工具可以帮助确认前缀和可用键，但仍建议按前缀分块整理。

server.port=8080
spring.datasource.url=jdbc:postgresql://localhost:5432/app
spring.datasource.username=app
management.endpoints.web.exposure.include=health,info

迁移建议

不要为了统一格式一次性迁移所有配置。更稳妥的方式是先清理重复 key、确认当前 profile 覆盖关系，再从一个模块或一组配置开始迁移。

迁移后必须用相同启动参数验证最终配置值，尤其是端口、数据源、日志级别和 Actuator 暴露范围。格式变了，不代表运行时结果一定等价。

相关文章

本站由 ErickPang 独立维护，与 Spring、JetBrains 或 Broadcom 无官方关联。