JSON.parse()报错主因是后端返回非合法JSON，如日志干扰、错误HTML响应、未校验状态码；应优先用response.json()并检查response.ok，避免重复调用、结构误判、日期字符串解析风险及忽略边界响应。
JSON.parse() 报错：Unexpected token
这是最常见的前端解析失败现象，本质是后端返回的不是合法 JSON。常见原因包括：
后端日志打印干扰（比如在 JSON 前后多输出了 console.log 或调试字符串）；
HTTP 状态码非 200 但前端仍调用 JSON.parse()（例如返回了 HTML 格式的 500 错误页）；
响应头未设置 Content-Type: application/json，但更关键的是——前端没检查 response.ok 或状态码就直接解析。
实操建议：
- 始终先检查
response.status和response.ok，再调用response.json()（它内部已做格式校验，比手动JSON.parse()更安全） - 不要对
response.text()结果直接JSON.parse()，除非你明确知道内容结构且已 trim 过空格/换行 - 后端返回前加个简单校验：用
JSON.stringify()序列化后再返回，避免对象含不可序列化字段（如undefined、函数、循环引用）
fetch().then() 里 response.json() 被调用两次
很多人写成这样：
fetch('/api/user')
.then(res => res.json())
.then(data => console.log(data))
.then(() => fetch('/api/user').then(r => r.json())) // ❌ 错误：重复发起请求问题不在 JSON，而在逻辑误把「解析响应」当成「发起请求」。实际上 response.json() 是一个 Promise，它只负责从响应体中读取并解析 JSON，不触发网络请求。
正确做法是复用已解析的数据，或封装成函数：
- 需要多次使用时，把解析结果存为变量，而不是反复调用
fetch().then(r => r.json()) - 若需重试，应重新调用
fetch()，而非对同一个response.json()Promise 多次.then() -
response.json()只能消费一次 —— 它读取的是流式响应体，第二次调用会报错TypeError: Already read
后端返回数组但前端按对象解构，或反之
典型错误：后端接口 /api/users 返回的是数组 [{"id":1,"name":"Alice"}]，前端却写
const { users } = await response.json(); // ❌ 报错：Cannot destructure property 'users' of 'undefined'这是因为实际返回的是顶层数组，不是 { users: [...] } 包裹结构。
立即学习“Java免费学习笔记（深入）”；
应对方式取决于接口契约：
- 确认接口文档：是 RESTful 风格（直接返回数组），还是 BFF 层统一包装（如
{ code: 0, data: [...] }） - 前端不要硬编码结构，先
console.log(data)看真实响应体 - 必要时加运行时判断：
Array.isArray(data) ? data : data.data，但更推荐后端保持响应格式一致 - 避免在
fetch外层自动包装，比如强行套一层{ result: data }—— 这会让类型推导和错误定位变难
日期字段被当成字符串，无法直接 new Date()
JSON 标准不支持 Date 类型，所有时间都以字符串形式传输（如 "2024-06-15T08:30:00Z"）。前端拿到后仍是字符串，new Date(str) 虽能工作，但存在兼容性风险（IE 对 ISO 格式支持弱，部分安卓 WebView 解析失败）。
稳妥做法：
- 后端尽量用标准 ISO 8601 格式（带
Z或时区偏移），避免"2024/06/15"这类模糊格式 - 前端统一用
new Date(Date.parse(str))或更可靠的库如date-fns/parseISO - 如果项目用 TypeScript，可在解构时用类型守卫过滤：
if (typeof item.createdAt === 'string') { ... } - 不要在
JSON.parse()里传第二个参数（reviver 函数）自动转日期 —— 容易误转其他数字字符串（如手机号、ID）
