前端错误处理：try/catch 与 Promise 的正确姿势

这里有几个概念：

一个常见的坑

很多人习惯这样写：

try {
  const res = await fetch('/api/user/list');
  const data = await res.json();
  return data;
} catch (e) {
  console.error('请求失败', e);
}

但这有个隐蔽问题：fetch 在收到 4xx、5xx 这些 HTTP 错误状态码时，并不会抛出异常。只有当网络彻底不通、跨域被拦截等底层错误发生时，才会抛出异常。所以上面的代码会把 404、500 当成成功处理，直接跑进 res.json()，可能接着解析到一堆乱七八糟的响应体。

怎么处理才对

要同时兜住网络异常和 HTTP 状态异常，一般这么做：

async function fetchUserList() {
  try {
    const res = await fetch('/api/user/list');
    if (!res.ok) {
      throw new Error(`HTTP ${res.status}: ${res.statusText}`);
    }
    const data = await res.json();
    return data;
  } catch (e) {
    if (e.name === 'TypeError' && e.message.includes('fetch')) {
      console.error('网络异常，请检查网络');
    } else {
      console.error('请求失败:', e.message);
    }
    throw e; // 让调用方也知道失败了
  }
}

要点：

• 用 res.ok 先判断状态码是不是 2xx；不是就主动抛一个错误
• res.json() 若遇非法 JSON 也会抛异常，能被同一个 catch 接住
• 网络类错误特征比较明显（TypeError 里包含 'fetch'），可以在 catch 里区分一下提示

3. JSON 解析这个小坑，得封个 safeParse

后端返回的东西不一定靠谱：可能直接是个字符串 "用户不存在"，也可能结构错乱。前端里直接 JSON.parse，一崩就是一片。

我一般会在项目里放一个 safeParse 工具函数：

function safeParse(str, fallback = null) {
  try {
    return JSON.parse(str);
  } catch (e) {
    console.warn('JSON 解析失败:', e.message, '原始内容:', str?.slice(0, 50));
    return fallback;
  }
}

const data = safeParse(response, {});

这样解析失败时不会让整个页面挂掉，而是静默回到一个兜底值（空对象或空数组），同时控制台里打一条 warn，方便查问题。

4. 业务异常和系统异常，分开处理

如果所有错误都不加区分地用 catch 糊成一团，用户界面上可能看到'网络异常'但其实是余额不足，或者技术错误细节直接暴露。所以得把两类错误分开。

业务异常——那些可以预料到的'业务上的失败'：余额不足、未登录、参数错误等等。后端通常会通过业务码（如 code: 'BALANCE_INSUFFICIENT'）和人类可读的消息返回。这类错误要明确提示用户，让用户知道下一步该做什么。

系统异常——网络断了、服务器 500、JSON 解析炸了、未知的运行时错误。这些不该把细节暴露给用户，应该上报监控，用户只看到一个通用的'系统繁忙'之类的提示。

下面是一个下单接口的例子，同时处理这两类：

async function placeOrder(orderData) {
  try {
    const res = await fetch('/api/order/create', {
      method: 'POST',
      body: JSON.stringify(orderData),
    });
    const text = await res.text();
    const data = safeParse(text, null);

    if (!res.ok) {
      // 业务异常：有明确的业务码
      if (data?.code === 'BALANCE_INSUFFICIENT') {
        return { success: false, type: 'business', message: '余额不足，请先充值' };
      }
      if (data?.code === 'UNAUTHORIZED') {
        return { success: false, type: 'auth', message: '请先登录' };
      }
      // 其他 4xx/5xx 当成系统异常往上抛
      return { success: false, type: 'system', message: data?.message || '服务器异常，请稍后重试' };
    }
    return { success: true, data };
  } catch (e) {
    // 系统异常：网络错误、JSON 解析异常等
    reportError(e);
    return { success: false, type: 'system', message: '网络异常，请检查网络后重试' };
  }
}

调用方就能清晰地分开提示：

const result = await placeOrder(formData);
if (result.success) {
  // 跳转成功页
} else if (result.type === 'business' || result.type === 'auth') {
  message.warning(result.message); // 可操作的业务提示
} else {
  message.error(result.message); // 系统异常，建议稍后重试
}

5. 几个实用的处理规范

• 该用 try/catch 的地方：JSON.parse、可能抛异常的第三方库、同步业务校验逻辑
• 别指望 try/catch 的地方：异步回调、事件监听器里的错误。这些要用 Promise 的 .catch()，或者 async/await 搭配 try/catch 包住 await 那一行
• 全局兜底：别忘了挂一个 window.onerror 或监听 unhandledrejection，来捕获那些漏网之鱼

下面把上面提到的 safeParse 和错误分类思路整合成一个带错误上报的产品详情接口：

async function getProductDetail(id) {
  try {
    const res = await fetch(`/api/product/${id}`);
    const text = await res.text();
    const data = safeParse(text);

    if (!res.ok) {
      if (data?.code === 'NOT_FOUND') {
        return { ok: false, reason: 'product_not_found' };
      }
      throw new Error(data?.message || `请求失败：${res.status}`);
    }
    return { ok: true, data };
  } catch (e) {
    if (e.name === 'SyntaxError') {
      reportError(e, { context: 'JSON 解析', id });
      return { ok: false, reason: 'parse_error' };
    }
    if (e.message?.includes('fetch') || e.message?.includes('Network')) {
      return { ok: false, reason: 'network_error' };
    }
    throw e; // 未知错误继续向上抛，让全局兜底处理
  }
}

最后

前端错误处理没有一招鲜，关键是把'预期的业务失败'和'真正的意外异常'拆开，然后在合适的地方用合适的工具。下面这张表可以当速查用：

记这几点，线上排查和用户体验都能轻松不少。