JSON解析崩溃主因是前端未校验输入或误析HTML，排查需三步：查原始响应内容、辨错误类型、验输入合法性；应封装safeParseJSON统一处理并检查response状态。
JSON 解析崩溃几乎总是由 SyntaxError 引发，而根本原因往往不是“后端没写对”，而是前端未做输入校验、未捕获异常、或把非 JSON 内容（比如 HTML 错误页）当 JSON 解析了。排查关键在于分三步：看原始响应、查错误类型、验证输入合法性。
检查原始响应内容，确认是不是 JSON
很多崩溃其实源于“解析了 HTML”。错误信息如 Unexpected token < in JSON at position 0 就是典型信号——说明响应开头是 <!DOCTYPE 或 <html。这时应直接打印原始文本，而不是只看错误堆栈：
- 用
response.text()获取完整响应体，再判断是否以{、[开头 - 检查
response.headers.get('content-type')是否含application/json，但不依赖它——网关错误时可能仍返回该 header - 若发现是 HTML，说明请求被重定向、认证失败、服务降级或网关拦截，需回溯网络请求链路（如 DevTools 的 Network 面板）
区分 SyntaxError 和其他异常类型
JSON.parse() 只抛 SyntaxError，但传入 null、undefined、空字符串也会触发它。不能一概 catch(e) { return null }：
- 检查
e instanceof SyntaxError—— 确认是格式问题 - 若
typeof input !== 'string'或input.trim() === ''，说明上游数据缺失，应提前拦截，而非等 parse 报错 - 其他错误（如
TypeError表示传了对象、RangeError可能是超大字符串）建议重新抛出或上报，避免掩盖真实问题
封装带上下文的解析函数，避免裸调 parse
每次手动写 try-catch 容易遗漏。推荐统一用一个健壮的解析工具：
立即学习“Java免费学习笔记（深入）”；
- 输入前过滤：跳过
null、undefined、非字符串、纯空白 - catch 中记录完整输入字符串和错误信息，便于复现
- 返回结构化结果，例如
{ ok: false, error: e, raw: input }，业务层可据此决定降级策略（如展示默认数据、提示用户重试） - 示例：safeParseJSON('{ "name": "Alice" }') → 返回对象；safeParseJSON('<html>...') → 返回错误对象并记录原始 HTML
配合 fetch 时，别跳过响应状态与类型检查
response.json() 是便利方法，但它内部仍调用 JSON.parse()，同样会崩：
- 必须先检查
!response.ok，状态码非 2xx 时不应继续解析 - 不要混用
response.json()和JSON.parse(await response.text())—— 前者是 Promise，后者是同步操作 - 若需预处理响应文本（如剥离 BOM、清理不可见字符），应先
await response.text()，再进 safeParseJSON
