如何通过 async 封装复杂异步逻辑的错误捕获

核心是让错误可预测、可分流、可恢复，通过结构化结果（如{error, result}）替代抛异常，统一用to封装、allSettled处理并发、分层归类网络/业务/未预期错误，并分层捕获与兜底。

核心不是堆 try-catch，而是让错误可预测、可分流、可恢复。关键在于把“出错”变成“返回一种确定结构”，而不是靠层层抛和捕来兜底。

用结构化结果替代抛异常

每个 await 都不直接 throw，而是统一包装成 { error, result } 形式。这样业务逻辑能主动判断，而不是被中断。

• 手写轻量封装：const to = p => p.then(res => [null, res]).catch(err => [err, null])
• 调用时：const [err, data] = await to(fetch('/api/user'))，后续直接 if (err) { ... }
• 避免在组件里写 fetch().catch(...)，破坏调用链，也难统一策略

并发请求用 allSettled 而非 all

多个异步操作并行时，别让一个失败拖垮全部。Promise.allSettled() 确保每项都有终态反馈，适合“尽力而为”场景。

• 比如批量拉取用户头像、权限配置、系统参数——某一项超时或 404，其余仍可用
• 结果是数组，每项含 { status: 'fulfilled' | 'rejected', value | reason }
• 配合结构化包装，可逐项提取成功数据，聚合失败原因用于上报或重试

分层处理不同类错误

网络错误、业务错误（如 401/422）、前端解析错误，不该混着 catch。一致性是指“每类有明确归宿”，不是“都用同一个 catch”。

• 网络层（断网、超时）：中止 loading、提示用户、可自动重试
• 业务错误（token 过期、无权限）：跳转登录页或弹窗引导，不计入主错误日志通道
• 未预期错误（JSON 解析失败、字段缺失）：捕获后打点上报，保留原始堆栈

顶层兜底 + 明确传播路径

不是所有错误都要在每个 async 函数里终结。合理分层才能减少冗余：

• 底层 API 函数统一封装 fetch，自动检查 response.ok 和业务 code，将错误转为结构化对象（含 code、message、data）
• 页面级 async 方法（如 onLoad）只做顶层 try/catch，控制 loading 状态和兜底 UI
• 全局监听 unhandledrejection，捕获漏网之鱼，防止白屏或静默失败