JSON 转 YAML：转换差异、边界与常见坑
在线 JSON 转 YAML：对「看起来像数字」的字符串加引号保护，多行值写成块标量，避免 YAML 解析器把字符串误读成数字或布尔；转换后建议再通读一遍关键值。
转成 YAML 的收益是可读性与注释能力（后者只有 YAML 侧才有）。代价是隐式类型：未加引号的 1.0、on、yes 会被当类型处理，字符串必须显式引号保护，这是 JSON 往返 YAML 最常见的语义漂移来源。
两种格式的差异对照
| 维度 | JSON | YAML |
|---|---|---|
| 注释 | 标准不支持 | 支持 # 注释，是配置场景的主要优势 |
| 缩进敏感 | 不敏感，靠括号与逗号 | 强敏感，缩进错误直接解析失败 |
| 隐式类型 | 字符串必须加双引号 | 未加引号的值会按内容推断类型（1.0 可能变字符串） |
| 多行字符串 | 用 \n 转义 | 支持 | 与 > 块标量，适合长文本 |
| 锚点与引用 | 不支持 | 支持 & 定义 / * 引用，可去重 |
| Tab 字符 | 允许（作为空白） | 禁止用 Tab 缩进 |
| 体积 | 括号与引号较多，稍大 | 通常更精简 |
| 解析速度 | 快，结构简单 | 较慢，类型推断成本高 |
边界条件
- 字符串看起来像数字或布尔时（"1.0"、"on"、"yes"、"null"）在 YAML 里会被类型化，必须显式加引号才能保持字符串。
- 以冒号或特殊符号开头的字符串同样需要加引号，否则会被当成映射键。
- 键名含点号时 YAML 不会拆成嵌套（那是 TOML 的行为），但消费端若按点号路径取值会造成混乱。
- 锚点在 JSON 侧不存在，反向转换（YAML→JSON）会把锚点展开成重复数据，体积膨胀且失去引用关系。
常见坑
- 不加引号直接输出，"1.0" 在消费端变成数字 1，版本号判断全部失效。
- 长文本被转成块标量，而消费端的解析库不支持，拿到一堆带 | 的原始字符。
- 把 YAML 里原有的注释当成"应该被保留"的信息，转换后还去找，白费力气。
- 中文与英文混排时缩进用 Tab 对齐，YAML 直接拒绝解析。
相关工具
- JSON 转 YAML把 JSON 转为缩进风格的 YAML，可自定义缩进宽度，适合改写成 K8s 清单与 GitHub Actions 工作流，让配置更易编辑对比。缩进宽度可调，多行字符串会自动改用块标量，避免出现大量转义符。输出适合直接粘进工作负载清单与流水线配置文件。注释式写法需自行补充。长文本会改用块标量输出。
- YAML 转 JSON把 YAML 解析并格式化为 JSON，自动保留嵌套对象、数组与多行字符串。完整支持锚点、别名与合并键，解析时会展开为等价的 JSON 结构。多文档 YAML 按顺序输出为数组，缩进错误会定位到具体行。也支持 JSON 文件粘贴后转换。输出缩进可调，便于直接嵌入代码。缩进错误会定位到具体行。
- 数据格式转换器在 JSON、YAML、TOML、XML、CSV 之间一处粘贴自由互转并实时预览。在 JSON、YAML、TOML、XML 与 CSV 之间任意互转，粘贴一次即可看多种输出。转换时会提示解析失败的位置，避免带着语法错误继续处理。适合在不同工具链之间迁移配置文件。支持粘贴即转。多种格式的输出可逐一取用。
常见问题
怎么把 YAML 再转回 JSON？
使用同工具的交换方向功能，或本站对应的「YAML 转 JSON」页面，两者都本地运行、数据不上传，可完成往返转换与校验。
JSON 和 YAML 哪个更适合人类阅读？
这取决于场景：YAML 通常更偏向程序解析与接口传输式的可读形态，而 JSON 更利于程序解析与接口传输式的程序消费；需要人工编辑时优先选可读性更高的那一侧。
JSON 里的多行字符串转成 YAML 后变成 | 或 > 了，有区别吗？
有。| 是字面块（保留换行），> 是折叠块（把换行换成空格）。两者语义不同，转换器通常按"原文是否含换行"选择。如果你的消费端不解析块标量，就会拿到错误的字符串——需要时手动改成双引号加 \n 写法最保险。
注释能保留吗？
不能。JSON 标准不支持注释，所以 JSON 里根本没有注释可保留。反方向（YAML → JSON）时，YAML 里的注释会在转换中被丢弃，这是格式能力的差异而非工具缺陷——需要保留注释就必须留在 YAML 侧。