上周三下午，我把一个 300 行的 Kubernetes Deployment 从 JSON 格式改成 YAML，准备提交到 Git 仓库。复制粘贴到编辑器里手动缩进，改了 20 分钟还没弄完，最后用 quan77.cn 的 JSON 转 YAML 工具，几秒钟就拿到了结构正确的 YAML。但粘贴回文件后，发现原本写在 JSON 里的注释全没了，锚点引用也变成了普通字符串。这个工具确实快，但配置文件转换远不止格式替换。
为什么直接转换会丢注释和锚点？
JSON 标准本身不支持注释，所以很多开发者会把注释写在 JSON 的 _comment 字段里，或者用 // 开头但不符合规范。quan77.cn 的转换器按标准 JSON 解析，遇到这些非标准内容会直接忽略。锚点更麻烦，JSON 没有引用概念，YAML 的 &anchor 和 *ref 在 JSON 里只能写成重复的完整对象，转换后自然变成两份独立数据。
我拿三个真实场景试了试，发现规律很清楚：纯数据转换（API 响应、配置文件无注释）完全没问题，但带注释或锚点的配置需要额外处理。
三个真实场景分别怎么用？
场景一：Kubernetes 清单，注释写在 _description 字段
我的 Deployment 文件里，每个资源都有 _description 字段说明用途。转换后这些字段保留在 YAML 里，但注释语义没了。正确做法是转换前先手动把 _description 字段值提取出来，转换后再作为 YAML 注释加回去。工具本身不帮忙，但至少结构没乱。
场景二：Ansible Playbook，用 YAML 锚点复用变量
Ansible 任务里经常有 defaults: &defaults 这种写法。JSON 不支持，所以源文件只能重复写。转换后 YAML 里是两份相同内容，我手动改回锚点引用，工作量比从头写少很多，因为工具保证了缩进和键顺序正确。
场景三：OpenAPI 规范，多行描述被转成转义字符串
OpenAPI 的 description 字段常有多行文本。JSON 里用 \n 转义，转换后 YAML 里是带转义符的单行字符串，可读性差。我试了 quan77.cn，发现它没有自动展开成 YAML 的 |- 块状语法，需要我手动替换。但键名和层级都没错，比手工重写省力。
什么时候别用它？
如果你要转换的文件里注释和锚点占比超过 30%，或者注释是给团队看的协作信息（比如 // TODO: 需要更新），建议别用在线工具直接转。因为转换后注释全丢，你还要手动补，不如直接在编辑器里用插件（比如 VS Code 的 YAML 插件）做保留注释的转换。另外，如果文件超过 1MB，在线工具可能会超时，我试过 2MB 的 JSON 直接卡住，最后用 Python 脚本解决的。
搭配哪些工具更顺手？
转换前先用 JSON 格式化工具 检查 JSON 合法性，避免转换报错。转换后用 YAML Lint 校验语法，特别是手动补锚点后容易出错。这两个搭配下来，效率比纯手动高很多。
转换后如何手动补回注释和锚点？
如果你必须用 quan77.cn，转换后按这三步补：
- 先看源 JSON 里哪些字段名以
_开头（如_comment），这些就是注释载体，转换后手动提取为 YAML 注释。 - 检查是否有重复的完整对象，如果有，说明源文件里可能是锚点引用，转换后需要手动改成
&anchor和*ref。 - 多行字符串用
\n的，手动替换为 YAML 的|-块状语法，注意缩进。
这三个步骤做下来，转换质量能提升 80%。但如果你嫌麻烦，还是建议用支持注释保留的本地工具。
总结：这个工具适合什么场景？
quan77.cn 的 JSON 转 YAML 最适合纯数据转换，比如把 API 返回的 JSON 转成 YAML 配置文件，或者把测试数据转成 YAML 格式。它快、免费、无广告，输出格式标准。但涉及注释、锚点、多行文本时，你需要额外处理。我的经验是：先转，再补，别指望一步到位。
如果你经常处理带注释的配置，建议把转换后的 YAML 保存为模板，下次直接改模板，省得每次补注释。