JSON vs YAML vs XML：到底该用哪种数据格式？

每隔几个月，团队里就有人挑起关于数据格式的争论。"这里为什么用 JSON？YAML 明明更简洁。"或者，"XML 有 schema，我们应该用那个。"

事实是，没有一种格式在所有场景下都是最好的。每种格式的存在都是因为它能很好地解决特定的问题。让我来分析一下各种格式什么时候真正合适。

快速决策矩阵

| 特性 | JSON | YAML | XML | |------|------|------|-----| | 可读性 | 良好 | 优秀 | 较差 | | 解析速度 | 快 | 中等 | 慢 | | 注释支持 | 无 | 有 | 有 | | Schema 验证 | JSON Schema | 有限 | XSD（强大） | | 数据类型 | 基础 | 丰富 | 基于字符串 | | 空白敏感 | 否 | 是（小心！） | 否 | | 文件大小 | 小 | 最小 | 大 | | 浏览器原生支持 | 是 | 否 | 部分 | | 最适合 | API、配置 | 配置、DevOps | 文档、企业级 |

JSON：Web 的通用语言

JSON 赢得了 Web。每个 API 都在用它，每个浏览器都原生解析它，每种语言都有内置支持。如果你在构建 REST API，选择已经定了。

JSON 的优势：

• API 请求和响应
• 包清单（package.json、composer.json）
• 服务间数据交换
• 任何需要快速解析的地方

不足之处：不支持注释。你没办法在 JSON 配置文件里说明某个值为什么这样设置。有人用 "_comment" 键来绕过，但那是个取巧的办法。

YAML：人类友好的选择

YAML 的设计初衷就是让人先读懂。没有花括号，大多数字符串不需要引号，随处可以加注释。DevOps 团队很喜欢它——Kubernetes、Docker Compose、GitHub Actions、Ansible——都选择了 YAML。

但 YAML 有个陷阱：空白很重要。缩进错一个，整个配置就废了。错误信息呢？通常没什么帮助。200 行配置里出现 "Mapping values are not allowed here" 真的说明不了什么。

而且 YAML 的类型转换可能让你吃惊。yes 变成 true。3.10 变成 3.1。挪威的国家代码 NO 变成 false。这不是 bug——是在你最意想不到的时候咬你一口的特性。

XML：企业级的主力

XML 现在被骂得很多，有些确实该骂。它太啰嗦了。JSON 里一行的简单键值对，XML 里要三行。

但 XML 能做其他格式做不到的事。XSD schema 提供强大的验证——可以强制执行数据类型、模式、必填字段，甚至值范围。XSLT 可以转换文档。命名空间可以防止合并不同来源文档时的命名冲突。

如果你在医疗（HL7）、金融（FIXML）或出版（DocBook）领域，XML 不会消失。这些行业选择 XML 就是因为它的严格，而这种严格正是他们需要的。

什么时候用什么

选择 JSON：

• 构建 Web API
• 存储简单配置
• 前后端数据交换
• 需要快速解析和广泛语言支持

选择 YAML：

• 编写 CI/CD 流水线
• Kubernetes 或 Docker 配置
• 需要注释的人工编辑配置文件
• 需要无转义字符的多行字符串

选择 XML：

• 与要求 XML 的企业系统协作
• 需要强大的 schema 验证
• 混合内容文档（文本中嵌入数据）
• 需要命名空间来组合文档类型

格式间转换

实际工作中，你经常需要在格式之间转换。也许你在把旧的 XML 配置迁移到 YAML，或者需要把 YAML 转成 JSON 给 API 用。

三种格式之间的结构映射相当干净。对象变成映射变成元素。数组变成序列变成重复元素。棘手的部分是 XML 的属性（JSON 和 YAML 中没有直接对应）和注释（转换为 JSON 时会丢失）。

你还可以在 XML 和 JSON 之间转换，或者处理表格数据时在 CSV 和 JSON 之间转换。

真正的答案

用你的生态系统期望的那个。写 Kubernetes 配置就用 YAML。构建 Web API 就用 JSON。在企业医疗领域就用 XML。

不要与工具和团队的惯例对着干。最好的数据格式是项目里每个人都已经理解的那个。

---

数据格式的争论很有趣，但很少像我们想的那么重要。选一个适合你用例的，保持一致，然后去解决真正的问题。你的用户不在乎配置文件是用花括号还是缩进。