JSON、YAML、XML 怎么选

三种格式都能表达嵌套数据。选错的代价通常不是「不能用」，而是联调时互相转一层，注释丢了、类型漂了、缩进炸了。下面按场景说，不搞格式鄙视。

对照

REST、大多数 RPC 网关、前端 fetch，默认就是 JSON。体积比 XML 小，解析实现到处都是。除非对端是老 SOAP 或行业强制 XML（部分政务、金融报文），新接口不要为了「看起来正式」上 XML。

GraphQL 的 body 也是 JSON。gRPC 用 protobuf，那是另一条线，和这三种文本格式不是互相替换关系。

Kubernetes、GitHub Actions、Docker Compose 用 YAML，因为人要写注释、写很长的列表。代价是缩进：Tab 和空格混用、同级对不齐，报错行号经常指到下一节。

YAML 还有隐式类型：NO、off 在旧版可能被当成 boolean。1.0 和 "1.0" 也不总是你想的那样。挪威国家代码 NO 当年还闹过笑话。新项目若团队不熟 YAML，配置用 JSON 或 TOML，少很多「为什么变成 false」。

JSON 做配置的缺点是不能写注释。可以用旁边的 README，或改用 JSONC（要接受「不是所有工具都认」）。

同一段里既有属性又有子节点、还要夹纯文本，JSON 会很丑（#text 这种键）。Office、部分出版和老企业总线仍是 XML。新业务文档如果只是结构化字段，不必为了「行业习惯」强行 XML。

转完不要只看「能 parse」。用树把关键路径对一遍，尤其是列表长度。HiJSON 读的是 JSON；YAML/XML 先在你们的转换步骤里变成 JSON，再贴进来查，见树视图。

{
  "service": "checkout",
  "replicas": 2,
  "env": ["prod"]
}

YAML 大致是：

service: checkout
replicas: 2
env:
  - prod

XML 会变成一串标签，replicas 到底是属性还是子元素，两边要先说好。没有「正确的 XML」，只有你们契约里的那一种。