JSON vs YAML vs TOML：配置文件的抉择艺术

引言：为什么我们需要这么多格式？

在软件开发中，数据序列化格式无处不在：从 API 响应到应用配置，再到 CI/CD 流水线。虽然它们都能表达结构化数据，但设计目标却大相径庭。

选择错误的格式可能会导致配置逻辑复杂化、解析性能下降，甚至引发难以察觉的语法错误。

JSON 是目前的工业标准，它是 JavaScript 的一个子集。

设计哲学：极简、易于机器解析。
优点：
- 通用性：几乎任何编程语言都内置了 JSON 支持。
- 确定性：语法规则极少，解析速度极快。
痛点：
- 不支持注释：这是配置文件最大的硬伤。
- 语法冗余：大量的括号和引号，手写起来很痛苦。
- 末尾逗号：最后一个元素后面不能有逗号，经常导致语法报错。

YAML 是一种以缩进为核心的格式。

设计哲学：以人为本，可读性至上。
优点：
- 极其简洁：没有括号，减少了视觉干扰。
- 支持注释：非常适合编写复杂的 CI/CD 或 K8s 配置。
- 功能强大：支持引用（Anchors）和多行字符串。
痛点：
- “缩进地狱”：一个空格的错误可能导致逻辑完全改变，且极难排查。
- 过于复杂：规范极其庞大，导致不同解析器的行为可能不一致。
- 挪威问题：著名的 NO 被解析成布尔值 false（虽然 YAML 1.2 修复了此问题）。

TOML 是近年来兴起的强有力竞争者，被用于 Rust 的 Cargo 和 Go 的 Hugo。

设计哲学：语义化、无歧义、映射到哈希表。
优点：
- 易读性：类似于传统的 .ini 文件，但功能更强。
- 强类型：对日期、时间、整数、浮点数有明确的定义。
- 无歧义：相比 YAML，TOML 的解析规则非常明确，不容易出错。
痛点：
- 层级表达：在处理非常深的嵌套结构时，方括号语法会变得有些臃肿。

假设我们要定义一个数据库连接配置：

{
  "database": {
    "server": "192.168.1.1",
    "ports": [8000, 8001, 8002],
    "connection_max": 5000,
    "enabled": true
  }
}

database:
  server: 192.168.1.1
  ports:
    - 8000
    - 8001
    - 8002
  connection_max: 5000
  enabled: true # 支持行内注释

[database]
server = "192.168.1.1"
ports = [ 8000, 8001, 8002 ]
connection_max = 5000
enabled = true

数据交换 (API)：首选 JSON。它是 Web 的母语，性能最高，兼容性最广。
复杂的编排与自动化 (CI/CD/K8s)：首选 YAML。虽然它有坑，但它的简洁和对多行字符串的支持在这些领域无可替代。
应用配置文件 (App Config)：首选 TOML。它比 JSON 友好（支持注释），比 YAML 稳健（不会因为空格报错），是目前最完美的配置文件格式。

最终建议：如果你在写一个新的 Rust 或 Go 项目，试试 TOML；如果你在写一个前端项目的 API，老老实实用 JSON。