后台点击上传，一个几十KB的JSON文件，页面瞬间弹出“解析失败”。不少人的第一反应是文件坏了，于是重新导出一遍再传，结果提示依旧。也有人把文件发给同事，对方用编辑器打开一切正常，于是开始怀疑服务器。实际上，网页端解析JSON失败的原因分布很广，文件本身出错只是其中一类，编码、语法、体积、解析环境任何一环出问题，都可能得到同一句笼统的报错。下面按由浅入深的顺序，把核对层次拆开说明。
第一层：先看文件编码和BOM头
JSON标准要求使用UTF-8编码，但“UTF-8”和“UTF-8带BOM”是两回事。部分编辑器在保存时会自动写入BOM头，也就是文件开头几个不可见字节。人眼看不出来，解析器却会把它当成正文的一部分，在第一个字符处就报错。核对方法很简单，用支持显示编码的编辑器打开文件，查看编码标识，或者用命令行工具读取文件头部字节。如果确认带BOM，另存为不带BOM的UTF-8即可。另外要注意，从表格软件导出或从聊天工具转存的文件，编码被改成GBK的情况也不少见，中文内容会先乱码再报错。
第二层：核对JSON语法本身
语法错误是最常见的一类，而且往往藏在细节里。重点检查四处：对象或数组最后一项后面是否多了逗号；键名和字符串是否误用了单引号，JSON只认双引号；文件里是否混入了注释，标准JSON不支持注释；文件末尾是否有导出工具追加的多余字符或空行之外的说明文字。还有一种隐蔽情况，数字被写成了带前导零的形式，或者出现了NaN、Infinity这类非标准值。用编辑器的JSON格式化功能过一遍，语法问题基本都会暴露出来。
第三层：核对文件大小与嵌套深度
有些文件语法完全正确，但就是传不上去。这时要看体积和结构。网页端上传通常有大小限制，服务端解析也有内存和超时约束，文件越大、嵌套越深，解析耗时越长，容易在超时后被统一报成解析失败。嵌套层级过深还会触发部分解析库的默认深度保护。核对时先看文件体积是否接近上传上限，再看数据结构是否出现多层数组套对象的情况。如果确实很大，可以考虑拆分上传或改为分片提交，而不是反复重传同一个文件。
第四层：核对网页端解析库版本与错误提示
前几层都没问题，就要看解析这一端。不同解析库对标准的严格程度不一样，旧版本可能不支持某些新语法，也可能对特殊字符处理不同。更常见的问题是错误提示被吞掉：前端捕获异常后只弹一句“解析失败”，真正的错误位置和原因没有输出，排查就变成了猜。核对时可以打开浏览器开发者工具，观察控制台和网络请求返回的具体信息，确认是前端解析报错还是服务端返回错误。这一步能大幅缩小范围。
上传前自检清单与排查顺序
建议按以下顺序操作：确认编码为UTF-8且不带BOM；用格式化工具检查语法，重点看逗号、引号、注释和尾部字符；确认文件体积在限制之内，嵌套层级合理；最后查看解析端的具体错误信息。这个顺序的原则是先排除文件问题，再排查环境问题，避免一上来就改动服务配置。
修复之后如何验证
修改完成后不要只传一次就结束。建议用原文件、修改后文件、一个已知正常的小文件分别上传，对比结果，确认问题确实出在改动的那一层。同时保留修改前后的文件副本，便于回溯。对于长期运行的网站，把上传失败的提示做得更具体，比如指出是编码问题、语法问题还是体积超限，能显著减少用户反复试错。it数运在网站维护中重视把错误提示说明白，让用户知道下一步该改什么，而不是只看到一个失败结论。技术问题的解决，往往从把问题说清楚开始。
