async封装实现异步任务容错设计

容错设计不是让 async 函数“不报错”，而是让错误变得可识别、可分类、可恢复。关键在于把错误来源拆开处理，而不是一股脑 try/catch 包住整个 await 链。下面具体展开实现方法。

区分错误类型，分层响应

async 任务的失败可能来自不同环节，混在一起处理会掩盖真实问题。网络层失败（如 fetch 超时、连接中断）适合重试加降级，返回缓存数据、默认值或兜底 UI。客户端校验失败（参数为空、格式错误）应在 await 前直接拦截，不进入异步流程。服务端业务失败（401、403 或自定义 error_code）需要解析 response.body，走 if/else 业务分支，而非当作异常抛出。解析失败（如 JSON.parse 报错）要单独捕获，避免与网络错误混淆。这四类错误各走各的路径，才能精准应对。

坚持单点 await + 显式 try/catch

每个 await 后面都应考虑是否需要独立捕获，尤其是链式操作。例如先 fetch 再 .json()，fetch 失败和 .json() 失败要分开 catch。避免写成 return fetch(...).then(...).catch(...)，这样会让函数实际返回 Promise，丢失类型推断。也不混用 then().catch() 和 await，否则上下文丢失、堆栈难追踪。此外，监听全局 unhandledrejection 事件，开发期报警，线上收敛日志，也是一个好习惯。

控制并发与重试边界

盲目重试或并发失控会放大故障。只有幂等操作（GET、PUT）才适合重试；POST/DELETE 重试前需确认服务端支持幂等（如带上 idempotency key）。重试次数通常限制在 2～3 次，首次延迟 100ms，后续指数退避（100ms → 300ms → 900ms）。并行请求允许部分失败？用 Promise.allSettled() 替代 Promise.all()。还可以封装通用 retry 工具函数，接收 fn、maxRetries、shouldRetry predicate，方便复用。

保证状态清理与副作用可控

async 执行常伴随 loading、定时器、事件监听等副作用，出错时必须归位。loading 状态在 try 外置为 true，在 finally 中统一设为 false。使用 AbortController 的请求，需在 catch 或 finally 中调用 abort()。在 React 等框架中，await 前检查组件是否已卸载，避免 setState on unmounted。最后，禁止静默吞错：即使降级也要记录 error.code、url、timestamp 等关键字段，方便排查问题。