JSON 工作流指南

什么时候最需要这套流程

当你怀疑某个 API 返回不对、某份配置被人手工改过、或者某批数据即将被转成别的格式时，这套流程最有用。核心是把三件经常被混在一起的事拆开：让 JSON 可读、证明 JSON 合法、以及把 JSON 安全地转换成下一个产物。

• 先格式化，让结构和嵌套关系暴露出来。
• 再做校验，把语法错误、尾逗号和非法引号明确标出来。
• 只有在源数据稳定之后，才进入比对或转换步骤。

一套安全的 JSON 检查顺序

先用格式化工具把嵌套层级和数组形态摊开，再进入校验工具获取带行号的解析错误。如果数据来自两个环境，不要先假设只有一个字段改了，而是先做差异比对。最后，只把已经清洗过的版本转换成 YAML、SQL、Markdown 表格或适合表格软件导入的行数据。

团队最常漏掉的问题

真正隐蔽的问题通常是语义层面的。某个字段有时是字符串、有时是数字，格式化不会报错；一个本来应包含对象的数组突然变成空数组，依然是合法 JSON，却会悄悄破坏后续推断；从 IM 或文档里复制出来的片段还常带有智能引号或不可见字符，这些通常只有在校验失败时才暴露。

• 不要把“格式化成功”等同于“可安全导入”。
• 改 Schema 前，先比对预发和生产样本。
• 给文档、测试和支持沟通保留一个统一的标准样本。

如何把工具串成工作流

最强的 JSON 体验从来不是单一页面，而是一条连续路径：先格式化看结构，再校验看合法性，再比对看漂移，最后把结果按接收方需要转成对应格式。这个接收方可能是研发、运维、客服、分析，甚至内容团队。