前端 fetch 网络断开时怎么区分 CORS 和真正连接失败

前端看到 fetch() 进入 catch，并不能直接断定“服务器没启动”或“就是 CORS”。对页面脚本来说，CORS 阻断、DNS/TCP/TLS 连接失败和部分请求中止都可能没有可用的 Response。真正可靠的判断方式是先看 Promise 分支，再把 Console、Network 和服务端日志拼起来。

一、先把 fetch 的结果分成两条路径

Fetch API 在服务器已经返回 HTTP 响应头时就可以 resolve，即使状态码是 404 或 500。因此，HTTP 错误不应该一律写进 catch。只有拿到 Response 后，才按 ok 和 status 做业务判断。

async function loadProfile() {
  try {
    // HTTP 4xx/5xx 仍可能返回 Response，不要只依赖 catch。
    const response = await fetch('/api/profile', { headers: { 'Accept': 'application/json' } });

    if (!response.ok) {
      // 把状态码交给业务层，区分未登录、限流和服务端错误。
      throw new Error(`HTTP_${response.status}`);
    }
    return await response.json();
  } catch (error) {
    // 这里既可能是 HTTP 分支主动抛出的错误，也可能是请求拒绝。
    console.error('profile request failed', { name: error.name, message: error.message });
    throw error;
  }
}

这段代码的关键不是把所有错误都变成同一个提示，而是先保留状态码。Response.ok 只在状态码为 200 到 299 时为 true；它不会告诉你 JSON 是否符合业务 schema，也不会替代超时和取消处理。

二、为什么 CORS 和网络失败都落到 catch

CORS 是服务器通过响应头告诉浏览器哪些源可以读取跨源资源的机制。浏览器可能已经发出了请求，但如果响应没有满足授权条件，脚本仍不能读取响应细节。出于安全原因，浏览器不会把“到底是哪个跨源检查失败”完整交给 JavaScript，所以代码里常见的结果只是一个拒绝。

这也是为什么把 catch (error) { if (error.message.includes('CORS')) ... } 当成正式判断并不可靠。跨浏览器的错误文本不是稳定接口；而真正断网、证书失败、域名解析失败或被浏览器拦截，也可能只得到 TypeError。

不要用 mode: 'no-cors'“修复”问题。它可能让请求变成 opaque response，脚本拿不到状态码和响应体，反而失去诊断能力。正确修复 CORS 的位置通常是 API 的响应头、预检 OPTIONS 处理和凭据配置，而不是前端偷偷改一个选项。

三、用最小诊断代码保留可判断证据

业务层可以把“能由代码确认的事实”和“需要外部证据的拒绝”分开。主动超时或用户取消要单列，否则用户点击离开页面时会被误报成网络故障。

async function requestJson(url, signal) {
  try {
    // signal 由调用方控制超时或页面离开时的取消。
    const response = await fetch(url, { signal, headers: { 'Accept': 'application/json' } });
    const requestId = response.headers.get('X-Request-Id');

    if (!response.ok) {
      // 保留 status 和 requestId，便于服务端按同一请求检索。
      return { kind: 'http', status: response.status, requestId };
    }
    return { kind: 'ok', status: response.status, data: await response.json(), requestId };
  } catch (error) {
    if (error.name === 'AbortError') {
      // 超时或主动取消是可解释状态，不要显示“网络断开”。
      return { kind: 'aborted' };
    }
    // TypeError 可能是 CORS，也可能是 DNS/TCP/TLS 或离线，需查外部证据。
    return { kind: 'transport-or-cors', errorName: error.name };
  }
}

生产日志至少保留请求路径、结果类别、HTTP 状态、错误名和脱敏后的 request id。不要为了排错把 Cookie、Authorization 或完整响应体直接打进前端日志。若还要解析 JSON，建议把解析失败单独归类，因为它说明响应已经到达，只是内容格式或读取过程出了问题。

四、用浏览器和服务端证据完成最后判定

最后一步不靠猜错误字符串，而是看三处证据是否互相吻合：

• Console：出现跨源策略、缺少 Access-Control-Allow-Origin 或预检失败的提示时，优先检查 CORS 配置。
• Network：看请求是否发出、是否先有 OPTIONS、是否能看到响应头和状态码。看不到可交付的响应不等于服务器没有收到请求。
• 服务端：按 request id 查入口日志、TLS/网关日志和应用日志；有入口记录但浏览器读不到，往往是响应暴露或预检问题，没有入口记录才更接近解析、连接或链路故障。

对应的用户体验也应分开：HTTP 401/403 显示登录或权限提示，5xx 显示稍后重试，CORS 问题提示联系接口维护方，真正的断网或超时进入重试和离线缓存。这样既不会把服务器错误伪装成“网络断开”，也不会让前端代码承担浏览器刻意隐藏的跨源细节。

相关问题

fetch 遇到 500 会不会自动进入 catch？

不会。只要浏览器交付了 HTTP 响应，Promise 通常会 resolve；应检查 response.ok 或 status。

能不能只通过 error.name 判断 CORS？

不能。普通拒绝的错误名不足以证明根因，需结合 Console、Network 和服务端日志。