JSON/YAML/TOML配置对比：开发者选型指南

JSON 源自 JavaScript，设计目标是轻量化跨平台数据交换，语法规则基于 ECMAScript 标准，优先保障机器解析的可靠性。RFC 8259 明确定义其核心用途为结构化数据的跨系统传输。

YAML 全称 YAML Ain't Markup Language，设计定位是人类可读的配置数据，优先降低人工编辑门槛，通过缩进结构简化层级书写，适配非技术人员编辑配置的场景。

TOML 全称 Tom's Obvious, Minimal Language，设计目标是明确语义的配置格式，主张配置语义可被清晰解析，通过显式分段和键值对结构，避免歧义性解读。

三种格式在常用特性上的差异，直接影响配置的编写体验。JSON 未预留注释位置，多数解析器不支持注释语法；YAML 和 TOML 均原生支持单行与多行注释，方便编写配置说明。

多行字符串和日期类型的差异，对应不同场景的需求：YAML 适合编写多行说明或模板内容，JSON 需通过转义处理换行，兼容性一致但编写繁琐。

JSON 最广为人知的问题是缺少官方注释支持，部分开发者使用注释后，更换标准解析器会直接触发解析失败，导致配置无法加载。部分衍生方案如 JSONC 补充了注释支持，但未纳入官方标准。

YAML 存在知名的 Norway 问题：当字符串为 20:03 格式时，部分解析器会将其自动转换为 Base60 时间类型，得到数值 1203，与预期的字符串值不符，该问题源于 YAML 隐式类型转换规则。

TOML 不存在隐式类型转换，所有值类型由语法明确标记，不会自动推导类型，因此不存在类似的歧义问题，类型结果符合编写者预期。

三种格式在不同技术栈中的采用程度存在明显分层。下表按应用场景汇总各格式的主流地位，以及对应生态中解析器的成熟程度。

不同格式互转时，存在固定的信息丢失边界，OKfmt 格式转换工具会基于语法支持情况保留合法信息，丢弃不兼容内容。JSON 转 YAML 或 TOML 时，不存在原生信息丢失，所有结构均可完整映射。

YAML 转 JSON 时，YAML 的注释和原生日期类型信息会丢失，JSON 不支持这两种特性；TOML 转 JSON 时，仅注释会丢失，所有结构类型均可完整映射。YAML 转 TOML 时，原生日期类型会转换为对应格式的字符串，注释可以完整保留。