JSON 工具箱

JSON 和 YAML 该怎么选

结论：JSON 用括号划边界、YAML 用缩进表达层级。机器交互选 JSON，人写配置选 YAML；两者可以互转，但注释、锚点、多文档这些特性在转换中会丢。

入门约 4 分钟发布于 2026-10-30更新于 2026-10-30
JSON 与 YAML 的适用场景对比

结论：机器之间传输数据用 JSON，人手动维护的配置用 YAML；需要注释、多行文本或锚点复用时优先 YAML，需要对所有语言无歧义解析时优先 JSON。

直观对比

JSON：

{
  "server": {
    "host": "127.0.0.1",
    "port": 8080,
    "cors": ["https://a.com", "https://b.com"]
  }
}

YAML：

server:
  host: 127.0.0.1
  port: 8080
  cors:
    - https://a.com
    - https://b.com

同一个结构，YAML 少了 6 个符号，多了一行注释的位置。

差异在哪

维度 JSON YAML
层级表达 括号、逗号 缩进
注释 不支持 支持
字符串 必须双引号，需转义 多数情况不用引号
多行文本 转义 \n 或用数组拼 `
复用 无 锚点 & 与引用 *
多文档 需要外层包数组 --- 分隔
解析速度 快，语法简单 慢，缩进规则复杂
歧义风险 极低 缩进错一格、no 被当布尔

最后一行是 YAML 的真正代价。country: NO 里的 NO 在 YAML 1.1 里是布尔 false（挪威的国家代码因此出过事故），version: 1.0 可能被解析成浮点数而不是字符串。JSON 没有这类隐式类型推断，写什么就是什么。

具体怎么定

选 JSON 的场景

  • 接口请求与响应体
  • 服务间消息、事件流
  • 数据库的 JSON 字段（MySQL、PostgreSQL 的 JSON 函数只认标准 JSON）
  • 需要被多种语言、多种工具无差别解析的数据
  • 体积敏感的场景：同样内容 JSON 通常比 YAML 小，解析也更快

选 YAML 的场景

  • Kubernetes、Ansible、GitHub Actions、Docker Compose——生态默认就是 YAML
  • 需要写注释解释每个字段为什么这么配
  • 有大量多行文本（证书、脚本、SQL），JSON 转义会难以维护
  • 同一份配置里重复结构多，锚点能省掉大段复制

互转时会丢什么

从 YAML 转 JSON：

  • 注释全部丢失
  • 锚点与引用被展开成重复内容，文件体积变大
  • 多文档只能保留第一个，或者外层包成数组
  • 日期、布尔等隐式类型会被固化，转回去时写法变了

从 JSON 转 YAML：

  • 数字与字符串的区分可能被弱化，"8080" 和 8080 在 YAML 里都需要显式引号才安全
  • 深层嵌套在 YAML 里缩进很长，可读性反而下降

所以互转适合「一次性迁移」或「临时查看」，不适合把两种格式当成同一份文件的两个视图长期双向同步。

常见问题

如何判断一份配置该用 JSON 还是 YAML？

先看这份文件的读者和维护方式：由程序自动生成、跨语言传输、需要长期稳定解析，就用 JSON；由人手动编辑、需要解释字段或保存多行文本，就用 YAML。两者都可以互转，但不建议把同一份配置长期维护成两种格式。

为什么 YAML 更容易出现类型歧义？

YAML 有隐式类型推断，NO、on、1.0 这类值可能被解析成布尔、日期或数字。JSON 只有显式类型，写字符串就必须加双引号，因此跨语言解析时更可预测。

YAML 转成 JSON 时是否会丢失注释和锚点？

会。YAML 的注释、锚点引用和多文档结构在转成 JSON 后无法保留，锚点会被展开成重复内容。需要保留这些信息时，应使用支持 Document API 的 YAML 库，而不是做对象往返。

相关工具

延伸阅读