粘进「JSON 格式化」后别急着滚动找规律。先看统计那一栏的四个数：嵌套深度、对象与数组各多少个、字符串/数字/布尔/null 各多少、键名总数。这几个数直接告诉你这份数据是宽表、深树，还是被截断的半截货，比肉眼翻十屏有效。
四个数分别说明什么
嵌套深度最有用。3 以内属于平铺配置，美化后从头读就行；6 以上每层都在做包装，逐层展开必然迷路，应先拍平成列名再看。多数接口返回在 4 到 6 之间，超过 8 层通常是把树形结构整个塞进了一个响应体。
对象数与数组数的比例决定处理路线。数组明显多于对象，数据本质是一张表，走 JSON 转 CSV 给业务方最省事；对象远多于数组，是多层配置，该用递归排序键名后再比对。两个数都接近零，多半内容根本不是 JSON，或者只解析到了开头一小段。
键名总数除以对象个数得到平均字段数：低于 3 多是大量占位对象，高于 30 说明有冗余宽对象，这时列筛选比通读划算。各类值的数量用来抓异常：null 占比高是接口没回填字段，不是你的解析有问题；布尔数为零但业务里明明有开关字段，往往是值被写成了字符串形式的真假字面量，后续程序判断会出错。
拿到数字的三个动作
- 粘贴或上传文件，确认解析成功并读出统计四项。
- 按深度选路：浅的直接美化压缩，深的先转 CSV 看横向分布。
- 对比两次导出的统计。同一接口两次结果键名总数差一成以上，就是数据结构变了，先查这个再去读日志。
用它做批量验收
如果你在维护一堆接口样例或配置快照，统计是唯一能自动化的比对项。把每份文件的四项数字抄进一张表，新样本进来先比这四个数：深度不变、对象数翻倍、键名总数同步翻倍，说明只是数据条数变了；深度莫名加一层，几乎一定是上游新增了一层包装（常见于加了统一响应外壳），下游按老路径取值的代码会集体取空。这种变化肉眼翻 diff 很容易漏，数字一眼就能看出。
统计救不了的场景
统计只数已有内容，不判断内容对不对。本站不做 JSON Schema 校验，只检查语法是否合法——字段该不该存在、日期格式对不对、数值范围合不合规，一个都查不出来。数组里元素数量是否符合预期、分页字段与实际条数是否一致，也要人工核对。文件建议控制在 20MB 以内，全程在浏览器本地完成，不上传服务器、不需要登录、不占每日转换次数。
想进一步了解解析报错怎么定位，可以看 JSON 解析错误修复。
底线判断：深度大不一定坏，字段多也不一定乱。真正要警惕的是数字对不上——对象数为零却有几千行文本，说明你拿到的根本不是完整 JSON，这时任何阅读和复制都是白费，回去找接口要全量数据才是正解。工具入口在 JSON 在线格式化。