JSON 与 YAML 怎么选

YAML 靠缩进表达层级、几乎不用引号括号,写配置确实舒服;但它的「聪明」也带来一批著名的坑。这篇讲清两者的取舍,以及互转时会丢什么。

同一份配置的两种写法

上面的例子里 YAML 明显更清爽:没有括号引号逗号,层级一眼看穿,还支持注释——这是它统治配置文件领域的原因(Docker Compose、Kubernetes、CI 配置几乎全是 YAML)。

{ "server": { "host": "localhost", "ports": [80, 443] } }

server:
  host: localhost
  ports:
    - 80
    - 443

规则少到几分钟学完,解析器行为完全一致,不存在「猜类型」;缩进错了立刻报语法错,而不是静默变成另一个结构。作为接口与程序间的数据交换格式,JSON 的严格是优点。

上面两行是真实事故源:挪威的国家码 NO 被解析成布尔值,1.10 被解析成 1.1。缩进混用空格与 Tab、多一格少一格,结构就悄悄变了。规范建议:所有字符串值一律加引号,别依赖裸值猜类型。

country: NO      # 挪威的国家码,却被解析成布尔 false / parsed as boolean false
version: 1.10    # 想要字符串版本号,却被解析成数字 1.1 / parsed as number 1.1

YAML 转 JSON 会丢注释与锚点引用,多文档流只能取其一;JSON 转 YAML 基本无损,但输出风格(块式 / 流式)会影响可读性。转完配置务必在目标环境跑一遍校验,尤其检查原来加引号的字符串有没有变类型。

人手写、人维护的配置文件选 YAML(记得字符串加引号);机器生成、机器消费的数据交换选 JSON。两者互转成本很低,不必二选一站队。