async函数中应按错误类型分类处理：网络错误可重试，业务错误需提示并分支处理，客户端逻辑错误须上报并重抛；每个await独立捕获，用allSettled避免单点失败阻塞，配合全局兜底与分类工具函数。

在 async 函数中按错误类型处理逻辑，关键不是统一 catch 后随便吞掉或抛出，而是把错误“分类识别 + 分类响应”。不同来源的错误该重试就重试，该提示就提示，该上报就上报，该终止就终止。

区分三类典型错误并分别应对

网络层、业务层、代码层错误性质完全不同，混在一起处理会掩盖问题本质：

• 网络错误（如 fetch 失败、超时、断网）：通常可重试。检查 error.name === 'TypeError' 且 message 包含 'fetch' 或 'network'，或用 AbortController 判断是否 timeout；可配合指数退避重试 2～3 次，失败后降级返回缓存或默认值
• 服务端业务错误（如 response.status === 401/403/404，或 data.code !== 0）：不是异常，是正常业务流分支。需 await response.json() 后主动判断，再 throw new BusinessError(data.msg, data.code)，让上层 UI 显示对应提示（如登录过期跳转、无权限隐藏按钮）
• 客户端逻辑错误（如 TypeError: Cannot read property 'xxx' of undefined、ReferenceError、JSON.parse 失败）：属于 bug，不应静默处理。记录 stack 和上下文（如当前 URL、用户操作步骤），上报监控系统，并保留原错误 re-throw，便于快速定位修复

每个 await 都要独立判断失败可能性

一个 async 函数里常有多个异步步骤，每一步失败原因和恢复方式不同，不能全包进一个 try：

• fetch() 失败 → 网络问题，可重试
• response.json() 失败 → 响应非 JSON 或格式损坏，属服务端数据问题，需单独捕获并提示“数据异常”
• 业务校验失败（如 if (!data.user) throw new Error('用户信息缺失')）→ 属于流程校验，应走业务错误分支，而非当异常兜底

推荐写法：对每个可能出错的 await 单独包裹 try/catch，或用 safeAwait / to 工具函数解构 [err, res]，避免错误类型被模糊化。

并行请求中保留各路结果状态

多个无关请求同时发起时（如拉取用户、订单、配置），不应用 Promise.all —— 一个失败整条链中断。改用 Promise.allSettled：

• 它返回数组，每项含 status（'fulfilled' 或 'rejected'）及对应的 value 或 reason
• 可遍历结果，对 fulfilled 项正常渲染，对 rejected 项单独标记“加载失败”，并提供“重试此模块”按钮
• 避免因单点故障导致整个页面空白或阻塞后续逻辑

全局兜底 + 统一错误分类工具

局部处理再细也会遗漏（比如事件回调里的 async、第三方 SDK 触发的异步操作）：

• 在应用初始化时监听 unhandledrejection：window.addEventListener('unhandledrejection', e => { /* 上报 e.reason，带页面路径、用户 ID */ })
• 封装通用错误分类函数，例如 isNetworkError(err)、isBusinessError(err)、isClientBug(err)，所有 catch 块优先调用它，再决定后续动作
• 避免重复写 if (err.message.includes('401')) —— 抽成 isAuthError(err) 更清晰、可测试、易维护