接口返回 200 但前端仍报错怎么办：从响应格式到跨域一步步排查

很多同学排查接口问题时会先看状态码：Network 面板里明明是 200，为什么页面还是提示请求失败、JSON 解析失败，甚至控制台还报跨域错误？原因是 HTTP 状态码只说明“服务器返回了响应”，不等于“前端拿到了可用数据”。

这类问题要按链路拆开看：请求是否真的发出、响应体是不是前端期待的格式、响应头是否正确、业务码是否成功、浏览器是否允许页面读取响应。下面按常见现象一步步排查。

适合人群

本文适合正在联调前后端接口、排查 Ajax/fetch 请求失败、接口状态码正常但页面仍报错的开发者。示例会同时给出前端和 PHP 服务端的处理思路。

目录

• 先区分 HTTP 成功和业务成功
• 第一步：看 Network 里的响应体
• 第二步：检查响应头和 JSON 格式
• 第三步：确认跨域和登录态
• 修复后的统一返回写法
• 常见坑位和最终验证

先区分 HTTP 成功和业务成功

HTTP 200 表示这次请求到达服务端，并且服务端返回了正常 HTTP 响应。但前端真正关心的是：响应体能不能被解析，业务码是不是成功，字段结构是不是符合页面预期。

例如下面两种响应，在 Network 里都可能显示 200，但前端处理结果完全不同。

{
  "code": 0,
  "msg": "ok",
  "data": {
    "id": 1001,
    "name": "demo"
  }
}

  login required

第二种返回的是 HTML，而前端如果按 JSON 去读，就会报解析错误。状态码正常并不能替代响应体检查。

第一步：看 Network 里的响应体

打开浏览器开发者工具，进入 Network 面板，选中这条请求。优先看三个位置：

• Headers：确认请求地址、方法、状态码、Content-Type。
• Response：直接看服务端返回的原始内容。
• Preview：看浏览器能不能把响应按结构展示出来。

如果 Response 里是登录页 HTML、错误模板、空字符串、半截 JSON，前端报错就很合理。此时不要只改前端兜底，应该回到服务端检查为什么返回了非预期内容。

第二步：检查响应头和 JSON 格式

如果接口本来应该返回 JSON，服务端应明确设置 JSON 响应头，并保证输出内容只有 JSON，不混入调试文本、警告信息或 HTML 模板。

 0,
    'msg' => 'ok',
    'data' => [
        'id' => 1001,
        'name' => 'demo',
    ],
];

echo json_encode($payload, JSON_UNESCAPED_UNICODE);

前端也不要直接假设所有 200 都是成功。建议先判断 HTTP 状态，再解析 JSON，最后判断业务码。

async function requestJson(url) {
  const res = await fetch(url, {
    credentials: 'include'
  });

  const text = await res.text();
  let body;
  try {
    body = JSON.parse(text);
  } catch (err) {
    throw new Error('响应不是合法 JSON');
  }

  if (!res.ok) {
    throw new Error(body.msg || 'HTTP 请求失败');
  }

  if (body.code !== 0) {
    throw new Error(body.msg || '业务处理失败');
  }

  return body.data;
}

第三步：确认跨域和登录态

有时服务端确实返回了 200，但浏览器不允许页面读取响应。典型场景是跨域响应头不完整，或者请求需要 Cookie 但前端没有携带登录态。

如果前端请求需要带 Cookie，fetch 需要设置 credentials，服务端也要返回匹配的跨域响应头。注意：带 Cookie 的跨域请求不能把允许来源简单写成通配符。

 0,
    'msg' => 'ok',
    'data' => [],
], JSON_UNESCAPED_UNICODE);

修复后的统一返回写法

为了减少联调成本，接口返回结构最好统一。成功和失败都返回 JSON，字段名保持稳定，前端只需要维护一套解析逻辑。

{
  "code": 0,
  "msg": "ok",
  "data": {}
}

{
  "code": 401,
  "msg": "请先登录",
  "data": null
}

如果用户未登录，不建议返回一整段 HTML 登录页给 Ajax 请求。更合理的做法是返回统一 JSON，由前端根据业务码跳转登录页或弹出提示。

常见坑位和最终验证

1. 响应里混入调试输出

接口输出 JSON 前后不要混入额外字符。一个空格通常没问题，但一段警告 HTML、调试文本或模板内容会导致 JSON 解析失败。

2. Content-Type 和内容不一致

不要返回 HTML 却标记成 JSON，也不要返回 JSON 却标记成 text/html。联调时先看 Headers，再看 Response。

3. 业务失败仍按成功处理

HTTP 200 下的 code 可能是 401、403、5001 等业务失败码。前端应该检查业务码，不要只看 HTTP 状态。

4. 跨域预检请求失败

如果请求方法、请求头或凭证配置触发了预检，需要服务端正确处理 OPTIONS 请求，并返回允许的方法和请求头。

总结

接口返回 200 但前端仍报错时，不要只盯着状态码。按顺序检查 Network、响应头、响应体、JSON 格式、业务码、跨域和登录态，基本就能定位问题。最终目标是让接口返回结构稳定，让前端用统一逻辑处理成功、失败和异常场景。