3、配置文件的格式之争：Properties、YAML、JSON、TOML 的对比与选择
说实话，配置文件这事儿，看着简单，选起来真头疼。
我见过不少团队，项目刚开始随便挑了个格式，结果后期维护时叫苦连天。我自己也踩过类似的坑——有一次用 JSON 做配置，结果连个注释都写不了，团队成员每次改配置都得靠猜。
今天咱们就把四种主流格式掰开揉碎，看看它们到底适合什么场景。
3.1 Properties：老牌劲旅，简单粗暴
Properties 文件，Java 出身的老将。格式就是纯粹的键值对：
# 数据库配置
db.host=localhost
db.port=3306
db.username=admin
db.password=secret
# 应用配置
app.name=MyApp
app.version=1.0.0
优点很明显：简单、直观、零学习成本。你想想看，连刚入行的新手都能一眼看懂。
但缺点也致命——不支持层级结构。你想表达一个数据库连接池的配置？对不起，只能靠命名约定：db.pool.maxActive=10。这在复杂场景下简直就是灾难。
适用场景：小型项目、Spring Boot 的 application.properties、简单的键值对需求。
我个人习惯：如果配置项少于 20 个，且没有嵌套结构，Properties 完全够用。别为了用 YAML 而用 YAML。
3.2 YAML：现代项目的宠儿
YAML 现在有多火？你看看 Kubernetes、Docker Compose、GitHub Actions，清一色全是 YAML。
它的核心优势是：可读性极强。用缩进表示层级，看着就像在看文档大纲：
server:
host: 0.0.0.0
port: 8080
ssl:
enabled: true
cert: /etc/certs/server.pem
database:
host: localhost
port: 5432
pool:
maxActive: 10
minIdle: 2
timeout: 30000
嗯，这里要注意：YAML 对缩进极其敏感。我曾经因为一个空格没对齐，排查了整整两个小时。说白了，YAML 的「可读性」是用「严格性」换来的。
避坑指南：我曾经在 YAML 里写了一个端口号 0123，结果 YAML 解析器把它当成了八进制数。后来我养成了习惯：所有数字都加引号，或者明确指定类型。
YAML 还支持锚点、别名、多行字符串等高级特性。但我的建议是：别用太花哨的功能。团队里不是每个人都熟悉 YAML 的奇技淫巧。
3.3 JSON：无处不在的通用格式
JSON 不需要我多介绍。前后端通信、API 响应、配置文件……哪儿都有它。
{
"server": {
"host": "0.0.0.0",
"port": 8080,
"ssl": {
"enabled": true,
"cert": "/etc/certs/server.pem"
}
},
"database": {
"host": "localhost",
"port": 5432,
"pool": {
"maxActive": 10,
"minIdle": 2,
"timeout": 30000
}
}
}
JSON 最大的优势是：几乎所有语言都有原生解析支持。你不需要额外引入任何库。
但缺点也很明显：不支持注释、语法冗余（大括号、逗号）、手写容易出错。你想想看，让你手写一个 200 行的 JSON 配置文件，你会不会崩溃？
适用场景：需要跨语言共享配置、API 配置、自动化工具配置。
我个人建议：JSON 适合做「机器读写」的配置，不适合做「人工维护」的配置。如果你需要频繁手动修改，换个格式吧。
3.4 TOML：后来居上的优雅方案
TOML 是 Rust 社区推起来的格式，现在 Python 的 pyproject.toml、Cargo 的 Cargo.toml 都在用。
它试图融合 Properties 的简洁和 YAML 的层级表达能力：
[server]
host = "0.0.0.0"
port = 8080
[server.ssl]
enabled = true
cert = "/etc/certs/server.pem"
[database]
host = "localhost"
port = 5432
[database.pool]
maxActive = 10
minIdle = 2
timeout = 30000
TOML 的语法非常清晰：[section] 表示层级，key = value 表示键值对。它支持注释、支持多种数据类型、支持内联表。
我个人习惯：新项目选配置格式时，优先考虑 TOML。它比 YAML 更安全（没有缩进问题），比 JSON 更可读，比 Properties 更强大。
3.5 横向对比：一张表说清楚
| 特性 | Properties | YAML | JSON | TOML |
|---|---|---|---|---|
| 可读性 | 高（简单场景） | 极高 | 中 | 高 |
| 层级支持 | 差（靠命名约定） | 优秀 | 优秀 | 优秀 |
| 注释支持 | 支持（#） | 支持（#） | 不支持 | 支持（#） |
| 类型安全 | 差（全是字符串） | 中 | 高 | 高 |
| 学习成本 | 极低 | 中 | 低 | 低 |
| 跨语言支持 | 中 | 高 | 极高 | 中 |
| 适合场景 | 简单键值对 | 复杂层级配置 | 机器间通信 | 项目配置文件 |
3.6 我的选择建议
说了这么多，到底怎么选？我总结几条实战经验：
- 项目配置文件：优先 TOML。它兼顾了可读性和表达能力，而且没有 YAML 的缩进陷阱。
- 容器编排/CI 配置：YAML 是事实标准，没得选。但记得用 lint 工具检查格式。
- 跨语言共享配置：JSON。虽然手写体验差，但解析器遍地都是。
- 简单场景（少于 20 项）：Properties 完全够用，别过度设计。
核心原则：配置文件的格式选择，取决于「谁来维护」和「怎么使用」。人工维护多的，选可读性强的；机器读写多的，选解析方便的。
最后说一句：不管你选哪种格式，一定要写注释。我见过太多项目，配置项的含义全靠猜。你想想看，半年后你自己回来看这些配置，还能记得每个字段是干嘛的吗？