JSON作为Web开发中最主流的数据交换格式，其解析过程看似简单，却频繁抛出"Unexpected token"类错误。这类报错信息往往晦涩难懂，仅提示一个字符位置和意外标记，让开发者难以快速定位问题根源。实际上，该错误的成因涵盖语法违规、数据来源异常、隐藏字符干扰等多个维度，需要系统性的诊断思路和针对性的解决方案。本文将从成因分析、诊断方法和解决方案三个层面进行详细拆解。
JSON语法格式违规：这是最直接的成因。JSON标准要求键名和字符串值必须使用双引号，使用单引号会触发Unexpected token '报错；对象或数组末尾多余的逗号（如{"name":"Tom",}）会导致解析器在右括号处报错；括号不匹配、缺失引号、未正确转义反斜杠或换行符等特殊字符，均会引发解析中断。
数据来源非JSON：这是线上环境最高频的成因。接口路径错误返回HTML 404页面、网关拦截返回登录页、服务端异常返回错误模板、响应为空或内容被截断，客户端却仍然调用JSON.parse()或res.json()解析，此时第一个字符往往是"<"，触发Unexpected token < in JSON at position 0报错。
隐藏字符与编码问题：文件开头携带UTF-8 BOM字符（\uFEFF）、字符串中混入零宽字符（\u200B-\u200D）或控制字符（\x00-\x1F），这些不可见字符在编辑器中无法察觉，但解析器会将其视为非法标记而报错。
多文档拼接与流式数据：当响应体包含多个JSON对象直接拼接（如{}{}），或流式接口返回NDJSON格式数据时，直接对整段文本调用JSON.parse()会因额外数据而报错。
检查HTTP状态码与响应头：在解析前打印response.status确认是否为200，检查Content-Type是否为application/json。若状态码为401/403/500或Content-Type为text/html，说明服务器返回的不是JSON而是错误页面。
查看原始响应体：通过浏览器开发者工具的Network面板查看Response标签页，或使用Postman/cURL直接请求接口，确认响应体前200个字符是否为合法的JSON开头（{或[），还是HTML标签（）。
使用在线工具验证格式：将响应体复制到JSONLint、VS Code内置JSON验证器等工具中，工具会精确定位语法错误的位置和类型，快速识别多余逗号、引号错误等问题。
检查文件编码：在VS Code状态栏查看文件编码，确认是否为UTF-8 without BOM格式，排除BOM字符干扰。
定位报错位置：根据错误信息中的position/offset数值，在原始字符串中定位到对应字符位置，观察该位置及其前后的内容，判断是语法问题还是隐藏字符。
修复JSON语法：确保所有键名和字符串值使用双引号，移除末尾多余逗号，补全缺失的括号和引号，正确转义特殊字符（如换行符使用\n、双引号使用），避免使用undefined、函数等非JSON合法值。
处理非JSON响应：在解析前增加前置校验，判断响应体是否以{或[开头，对非JSON数据进行日志记录而非直接解析；服务端应确保API接口统一返回JSON格式的错误响应，而非HTML错误页面。
清洗隐藏字符：封装清洗函数，在解析前使用正则表达式移除BOM字符、零宽字符和控制字符，确保输入为纯净的JSON字符串。
处理多文档数据：若数据包含多个JSON对象，应改为数组格式包裹，或按行分割为NDJSON逐行解析，不可直接对拼接文本调用JSON.parse()。
防御性编程：使用try-catch包裹解析逻辑，捕获异常后返回默认值或执行降级策略；对localStorage、Cookie等本地存储的数据，在读取后先验证再解析，防止过期或损坏数据导致崩溃。
JSON解析报错Unexpected token的排查核心在于"先看输入，再看解析"。90%的问题并非解析器本身有缺陷，而是输入数据不符合预期——要么是语法格式违规，要么是数据来源根本不是JSON，要么是隐藏字符作祟。诊断时应遵循"状态码→响应头→响应体→编码格式→语法验证"的顺序逐步排查，避免在解析代码上反复兜圈子。解决方案上，前端应做好防御性编程，使用try-catch和前置校验兜底；服务端应确保API接口返回统一的JSON格式响应，避免HTML错误页混入。掌握这套系统化的排查思路，可将JSON解析错误的定位时间从小时级缩短至分钟级，显著提升开发效率。
声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com
分享
苏公网安备 32059002001776号
