直接在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)。否则“统一处理”就只剩个壳子。
