怎样通过 async 封装实现异步任务的容错设计

容错设计是让 async 函数错误可识别、可分类、可恢复，需拆分网络层、客户端校验、服务端业务、解析失败四类错误并分层处理，坚持单点 await 与显式 try/catch，控制重试与并发，并确保副作用清理和错误上报。

容错设计不是让 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 等关键字段