直接在async函数中写try-catch不生效,是因为await仅捕获promise rejection,无法捕获http非2xx状态码或业务错误码等非js异常;必须分层校验网络层(如fetch失败)和业务层(如data.code≠0),并通过高阶函数封装统一处理。

为什么直接在 async 函数里写 try-catch 有时不生效
因为 await 只捕获当前 Promise 的 rejection,如果异步操作被包裹在 setTimeout、Promise.resolve().then() 或第三方库的回调中(比如某些 SDK 的事件触发),而这些内部没做 reject 或抛出异常,try-catch 就完全无感。更常见的是:你 await fetch(...) 成功了,但后端返回了 500 或 { code: 401 },这不算 JS 异常,catch 根本不会进。
封装前先明确错误分类:网络层 vs 业务层
统一处理 ≠ 一锅炖。必须区分两类错误:
-
fetch报错(如网络中断、DNS 失败、TypeError: Failed to fetch)——这是真正的异常,catch能捕获 - HTTP 状态码非 2xx(如
response.status === 401)或响应体含错误字段(如data.code !== 0)——这是业务约定,得手动判断
漏掉第二类,就等于“请求发出去了、没报错、但用户卡在空白页”,比报错还难排查。
推荐封装方式:用高阶函数 + 显式校验
不要试图让 try-catch 覆盖所有情况,而是把“可能出问题”的逻辑收口到一个函数里,再分层处理:
const safeRequest = async (promiseFn, options = {}) => {
try {
const res = await promiseFn();
// 1. 检查 HTTP 状态
if (!res.ok) throw new Error(`HTTP ${res.status}`);
// 2. 解析 JSON 并检查业务 code
const data = await res.json();
if (data.code !== 0) {
throw new Error(data.message || `API error: ${data.code}`);
}
return data;
} catch (err) {
// 统一打日志、上报、或触发全局错误提示
console.error('[API ERROR]', err);
if (options.onError) options.onError(err);
throw err; // 仍抛出,调用方可选择是否继续 catch
}
};
// 使用
safeRequest(() => fetch('/api/user'), {
onError: (err) => notifyUser(err.message)
}).then(data => console.log(data));
关键点:
- 传入的是
promiseFn而不是直接执行的 Promise,避免立即执行无法拦截 - HTTP 层和业务层校验都放在
try块内,确保它们都被纳入错误边界 - 不隐藏原始错误类型(比如保留
TypeError和自定义Error),方便后续按类型分流处理
React 中配合 Suspense / Error Boundary 的注意事项
如果你在组件里用 useEffect + async,别直接 await —— React 不支持异步 useEffect 回调,会静默忽略 catch。正确做法是:
- 在
useEffect里声明并调用一个普通 async 函数,且该函数内部必须有try-catch - 错误不能只靠
console.error,要同步更新 state(如setError(err)),否则 Error Boundary 捕不到 -
Suspense只对throw Promise敏感,不是任何异步错误都会触发 fallback,别混淆
最稳妥的边界还是回到函数封装层,而不是依赖框架机制兜底。
真正容易被忽略的,是业务错误码的映射表——比如后端返回 code: 1003 表示登录过期,这个值需要在封装层统一转成可识别的错误类型(如 AuthError),而不是每次都在组件里 if (data.code === 1003)。否则“统一处理”就只剩个壳子。










