JSON 与 YAML 的区别：语法严格度、注释与配置场景
JSON 与 YAML 都能表达键值结构和嵌套数据，但性格完全不同：JSON 像一丝不苟的合同，每个引号和逗号都有规定；YAML 像随手写的清单，靠缩进传意、允许省略引号。前者是 Web 数据交换的通用语，后者统治了 Kubernetes 和 CI/CD 的配置文件。
| 对比维度 | JSON | YAML |
|---|---|---|
| 语法风格 | 严格：键和字符串必须双引号（规范要求），花括号方括号定结构，机器生成零歧义 | 宽松：缩进即层级，键可不加引号，列表用短横线，人类手写体验更好但格式敏感 |
| 注释支持 | 标准不支持注释，配置文件里想留说明只能借助外部字段或预处理 | 原生支持 # 行注释，是运维配置能长期维护的关键原因之一 |
| 类型系统 | 六种类型固定：对象、数组、字符串、数字、布尔、null，行为在所有语言中一致 | 类型更丰富：多行文本块、日期、锚点引用与合并键；但「挪威问题」（no 被解析为 false）等隐式转换常埋坑 |
| 解析性能与安全 | 解析器极快且语言内建（如 JSON.parse），攻击面小 | 解析明显更慢；历史实现曾允许反序列化任意对象导致 RCE，必须选用安全模式加载器 |
| 出错概率 | 语法错误会被解析器精确定位到行列，修复直接 | 缩进错误、Tab 混用、类型误判最常见，且报错位置常常偏离真正出错的行 |
| 工具链生态 | Web 生态全覆盖：浏览器、数据库（PostgreSQL/MongoDB）、日志系统原生读写 | DevOps 事实标准：Kubernetes、GitHub Actions、Ansible、Docker Compose 全家桶 |
| 适用场景 | API 请求响应、前后端传输、机器生成或程序互读的数据 | 人工编写和维护的基础设施配置、部署清单、流水线定义 |
何时选 JSON？
数据在程序之间流动——API、消息队列、存储序列化——就选 JSON。它没有歧义、解析最快、任何环境都有现成库，也让自动化脚本不必担心缩进被编辑器改坏。
何时选 YAML？
文件主要由人来写、改、读——K8s 清单、CI 流水线、Compose 文件——就选 YAML。注释能力和低噪音语法让团队协作成本大幅降低，配合 schema 校验可以兜住大部分笔误。
相关在线工具
常见问题
JSON 真的不能写注释吗？
标准确实不允许。JSON 作者曾解释移除注释是为了防止实现间解析行为不一致。变通方案包括用 "_comment" 字段、JSON5/JSONC 扩展，或把说明放在外部文档里。
什么是 YAML 的「挪威问题」？
YAML 会把未加引号的 no 解析成布尔值 false 而不是国家代码字符串，on/off/yes 同理。给所有含歧义的字符串加上引号即可规避。
能把现有 JSON 直接改成 YAML 吗？
可以，两者表达力对嵌套结构完全等价，转换是无损的。注意转换后要检查数字开头的键、特殊字符值是否需要补引号。
延伸说明
实践中两者经常同框出现：GitHub Actions 用 YAML 定义工作流，工作流内部再处理 JSON 载荷；Helm 模板写的是 YAML，渲染产物交给 API 时已是 JSON。掌握互相转换比争论优劣更实用——站内的 JSON/YAML 互转与格式化工具可以在两种格式间一键切换并校验语法，本地处理不上传。记住一条经验法则：面向机器用 JSON，面向人用 YAML。