上传一份JSON文件，在浏览器里点击预览时却弹出报错，可下载到本地用编辑器打开又一切正常。这种“文件没坏、预览失败”的情况，在网站维护中并不少见。问题往往不在文件本身，而是从文件到页面的解析链路上，某一层的规则和这份文件对不上。与其反复重新上传，不如按下面的顺序逐层核对。
第一层：先看文件编码与BOM头
JSON标准要求使用UTF-8编码，但不少编辑器在保存时会自动加上BOM头，也就是文件开头多出几个不可见字节。带BOM的JSON在部分严格解析器中会直接被判为非法字符，预览自然报错。核对方法是查看文件开头是否有EF BB BF标记，或者用十六进制工具确认前几个字节。如果确实带BOM，去掉后重新上传，多数情况下预览就能恢复。
第二层：核对JSON语法本身
标准JSON不允许尾随逗号，对象或数组最后一个元素后面多一个逗号就会解析失败。单引号包裹字符串、用注释写说明、字符串里出现未转义的控制字符，同样属于非法写法。这些在JavaScript里可能被容忍，在标准解析器里却不行。可以用在线校验工具或命令行解析器先跑一遍，确认文件能被标准解析器正常读取，再进入下一层。
第三层：核对服务端解析配置
有些预览服务为了控制资源占用，会设置最大解析深度、最大文件长度或数字精度限制。嵌套层级过深的对象、超长的数组、超出精度范围的大数字，都可能在解析中途被截断并抛出异常。这一层要看的是服务端日志里具体的报错类型，是超长、超深还是数值溢出，而不是笼统的解析失败。
第四层：核对前端渲染环节
文件解析成功但页面仍报错，问题可能出在渲染上。大文件一次性渲染会拖垮页面，循环引用会让序列化陷入死循环，特殊字符未正确转义则可能破坏页面结构。核对时可以先在控制台确认数据是否已经拿到，再判断是渲染逻辑还是数据本身的问题。
把以上四层串起来，就是一份可执行的核对清单：确认编码无BOM，确认语法符合标准，确认服务端限制未被触发，确认前端渲染能安全处理数据。it数运在网站维护中处理这类问题时，通常按这个顺序从文件端向渲染端推进，先排除文件本身的问题，再逐层检查解析配置和渲染逻辑，避免一上来就归因于文件损坏。
JSON预览报错多数不是文件坏了，而是链路上某一层的规则没对齐。先确认文件能被标准解析器读取，再逐层排查解析配置与渲染逻辑，定位效率会高很多。
