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