async/await使Promise拒绝可被try/catch捕获，关键在于按业务逻辑分支分层捕获异常：登录、支付、上传等各环节独立处理，结合结构化错误码、Promise.allSettled区分并发失败，并明确错误吞并、转换或上抛意图。
async/await 本身不改变 JavaScript 的异常机制，只是让 Promise 拒绝（rejection）能被 try/catch 捕获，像同步错误一样处理。逻辑分支异常，指的是在不同条件路径下可能触发的异步失败——比如网络请求失败、数据校验不通过、权限不足、接口返回特定错误码等。关键不是“能不能捕获”，而是“在哪捕获”和“怎么区分处理”。
按业务路径分层捕获，避免全包式 try/catch
把整个 async 函数体用一个 try/catch 包住，看似省事，但会模糊错误来源，难以针对性响应。推荐按逻辑分支切分处理边界：
- 用户登录成功后跳转 → 登录失败时提示账号密码错误
- 支付前检查余额 → 余额不足时引导充值，而非统一弹“操作失败”
- 上传文件后生成缩略图 → 上传成功但缩略图失败，可降级展示原图
每个分支内嵌独立 try/catch 或提前判断，让错误处理与业务语义对齐。例如：
async function handleOrder() {
try {
const user = await fetchUser();
if (!user.hasPermission) throw new PermissionError('无下单权限');
} catch (err) {
if (err instanceof PermissionError) {
showPermissionDialog();
return;
}
throw err; // 其他错误继续上抛
}
try {
await submitOrder();
} catch (err) {
if (err.code === 'INSUFFICIENT_STOCK') {
showStockAlert();
return;
}
reportToSentry(err);
}
}
用 reject 值携带结构化错误信息
Promise 被 reject 时传入的值，不一定是 Error 实例。建议统一用带 code、message、level 的对象，方便分支识别：
- API 层：后端返回
{ code: 'USER_NOT_FOUND', message: '用户不存在' }，前端直接reject(data) - 工具函数：封装
fetchWithAuth，对 401 自动 reject{ code: 'AUTH_EXPIRED' } - 避免只 throw 字符串，否则
error instanceof XxxError失效
并发分支中单独控制每个 await 的容错
多个异步操作无依赖关系时（如并行加载用户信息+配置项），不应共用一个 catch。否则一个失败就中断全部，或掩盖具体哪个出错：
- 用
Promise.allSettled获取全部结果状态，再逐个判断status === 'rejected' - 对关键分支单独
try/catch，非关键分支可静默失败（如埋点上报失败不影响主流程） - 避免写成
const [a, b] = await Promise.all([fn1(), fn2()])—— 任一失败整个表达式 reject
示例：
const [userRes, configRes] = await Promise.allSettled([
fetchUser(),
fetchConfig()
]);
if (userRes.status === 'rejected') {
logError('用户获取失败', userRes.reason);
// 可 fallback 到本地缓存或空用户态
}
if (configRes.status === 'rejected') {
// 配置加载失败，不影响核心功能，仅禁用部分高级选项
}
错误传播要明确意图：吞掉、转换、还是上抛
不是所有异常都要在当前层消化。需根据调用方能否/应该处理来决定：
- 组件内异步：UI 层捕获，转为 loading 状态重置、toast 提示、按钮恢复
- 服务层异步（如 API client）：不处理业务错误，只包装网络超时、解析失败等底层异常，让业务层决定如何响应
- 公共工具函数：若失败无业务含义（如
debounceAsync中的 clearTimeout），可直接忽略；若有含义（如retryFetch最终仍失败），应 rethrow 原始错误或包装新错误
不推荐无差别 catch { return null } —— 这会让调用方无法区分“没数据”和“取数据失败”，后续逻辑易出错。
