前端错误处理实战：try/catch 与 Promise 用法

最基础的用法：

// 向 /api/user/list 这个地址发一个「我要数据」的请求
const res = await fetch('/api/user/list');
const data = await res.json(); // 把服务器返回的文本解析成 JSON 对象
console.log(data); // 拿到数据了

几个关键点：

**和 Ajax 的关系：**以前大家用 XMLHttpRequest 或 jQuery 的 $.ajax 来发请求，fetch 是浏览器后来提供的、更简单的新方式，本质做的都是同一件事：从浏览器向服务器发请求、拿数据。

搞懂这些后，下面就能理解为什么 fetch 的错误处理和你想的不太一样了。

2.2 常见误解

有人会这样写：

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

这里有个关键点：HTTP 4xx/5xx 并不会让 fetch 抛出异常，只有网络失败、跨域等才会抛。所以：

• 404、500 等错误 → 不会被 catch 捕获
• 网络断开、超时 → 会被捕获

2.3 正确做法

要同时处理'网络/请求异常'和'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，否则手动 throw
• res.json() 可能抛 JSON 解析错误，会被 catch 捕获
• 网络类错误在 catch 里单独分支处理

三、JSON 解析错误：最容易漏掉的一类

3.1 常见场景

后端返回的是字符串，或者格式不对：

// 后端返回："用户不存在"（纯字符串）
// 或者返回：{data: invalid}（非法 JSON）
const data = JSON.parse(response); // 直接崩

JSON.parse 抛的是 SyntaxError，如果不包一层 try/catch，会直接导致整段脚本报错，甚至影响后续逻辑。

3.2 推荐写法

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 方便排查问题
• 把解析逻辑封装成 safeParse，减少重复代码

四、业务异常 vs 系统异常：分类处理

很多人把所有错误都当成'失败'来处理，不做区分，交互和排查都会受影响。

4.1 业务异常（可预期的'业务失败'）

• 比如：余额不足、未登录、参数错误、权限不足等
• 通常由后端通过 HTTP 状态码 + 业务码 + 消息返回
• 需要展示给用户，并做相应业务流程处理

4.2 系统异常（程序/环境错误）

• 比如：网络断开、服务器 500、JSON 解析失败、未捕获的运行时错误
• 多半需要上报、告警，用户只看到通用错误提示

4.3 实战示例

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.1 该用 try/catch 的地方

1. JSON 解析：JSON.parse、res.json() 等容易抛错的地方
2. 可能抛出异常的第三方库：如日期解析、复杂计算等
3. 同步的、可能出错的业务逻辑：如参数校验、数据转换等

5.2 不要指望 try/catch 的地方

1. 异步回调：用 Promise 的 .catch、async/await 的 try/catch 包住 await 那一行
2. 事件监听：在回调里单独加 try/catch
3. 全局错误：用 window.onerror 或 unhandledrejection 做兜底

5.3 一个完整的小案例

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;
  }
}

六、总结

记住：不是所有错误都要用 try/catch，关键是区分'可预期业务失败'和'真正的异常'，在合适的地方用合适的工具处理。