应使用 try...catch 捕获并判断 error instanceof syntaxerror，解析前校验字符串非空且为合法 json 格式，检查 content-type、清理控制字符，并避免直接解析非 json 包裹内容。
JSON.parse 报错 SyntaxError: Unexpected token 怎么抓？
后端返回的字符串如果不符合 JSON 格式（比如多了逗号、用了单引号、包含 undefined 或注释），JSON.parse 会直接抛出 SyntaxError，不加捕获就崩。必须用 try...catch 包一层，且不能只 catch 通用错误——要专门识别解析失败。
实操建议：
- 永远把
JSON.parse放在try块里，不要假设后端一定返回合法 JSON -
catch中检查error instanceof SyntaxError，避免误吞其他类型异常（如网络中断导致的TypeError） - 打印原始字符串（
console.log('raw:', str)）比只打error.message更容易定位问题
后端返回的是 JSON 字符串嵌套在 HTML 或文本中怎么办？
常见于调试环境或旧接口：后端没设 Content-Type: application/json，或者返回了带 HTML 模板的响应（比如 "{"data":123}" 被包在 <pre class="brush:php;toolbar:false;"></pre> 里）。这时 JSON.parse 会因开头/结尾的非 JSON 内容报错。
实操建议：
- 先用正则粗筛：
str.trim().match(/{.*}/s)?.[0]提取最外层 JSON 片段（仅限简单场景，不推荐用于生产） - 更可靠的做法是检查
response.headers.get('content-type')?.includes('json')，再决定是否尝试解析 - 若明确知道包裹结构（如
{"result": "..."}中的result是 JSON 字符串），先JSON.parse外层，再对字段二次解析
为什么 JSON.parse(null) 不报错但返回 null？
这是 JSON.parse 的规范行为：输入 null 会被转成字面量 null，不是报错。但实际开发中，你拿到的往往是空字符串 ''、'null' 或 undefined，这些才会真正出问题。
实操建议：
- 解析前做基础校验：
if (!str || typeof str !== 'string' || str.trim() === '') { return null; } - 避免写
JSON.parse(str || '{}')—— 如果str是'undefined'，结果是{}，掩盖了真实问题 - 后端返回
'null'字符串（注意是字符串）时，JSON.parse('null')得到null，合理；但JSON.parse('undefined')必报错
需要兼容 IE8 吗？JSON.parse 有没有 polyfill 风险？
现代浏览器都原生支持 JSON.parse，IE8 及以下才需要 json2.js 这类 polyfill。但这类 polyfill 通常会覆盖原生方法，且部分版本对 reviver 参数处理不一致。
实操建议：
- 确认项目最低支持浏览器——2024 年绝大多数项目已无需兼容 IE
- 如果必须支持老 IE，用
npm install json3替代老旧json2，它更严格遵循标准 - 不要手动给
JSON.parse赋值（如JSON.parse = myParse），会破坏依赖它的库（如 axios 的响应转换逻辑）
最常被忽略的一点：后端返回的 JSON 可能含不可见控制字符（如 \u2028、\u2029），某些老版本 Node.js 或 Android WebView 会因此解析失败，而错误信息还是 Unexpected token——这时候得先 str.replace(/[\u2028\u2029]/g, '') 清理。
