async/await 优化数据加载重试需明确边界：仅对网络超时、503等临时错误重试，避免对401、404等业务错误盲目重试；在 try 中判断状态码或错误类型决定是否重试，并保留成功结果、处理失败项。
用 async/await 优化数据加载失败重试，核心是让重试逻辑清晰、可控、不阻塞主线程，同时避免盲目重试加重服务压力。关键不在“多试几次”，而在“什么时候试、试几次、怎么试”。
明确重试边界：只对可恢复错误重试
不是所有错误都适合重试。网络超时、503服务不可用、连接被拒绝这类临时性问题值得重试；而401未授权、404不存在、JSON解析失败等属于业务或逻辑错误，重试无效。
- 在 try 块中检查响应状态码或错误类型，匹配后再决定是否继续
- 例如 fetch 后判断：if (res.status >= 500 && res.status
- 封装一个 isRetryableError(err) 函数统一判断，便于维护和复用
控制重试节奏：用指数退避代替固定等待
连续立即重试容易触发“惊群效应”，尤其在服务刚恢复时可能瞬间压垮后端。指数退避让间隔随次数增长，给系统喘息时间。
- 第 1 次失败后等待 100ms，第 2 次等 200ms，第 3 次等 400ms……公式为 delay = base × 2ⁿ
- 加上随机抖动（如 ±20%），进一步分散请求时间点
- 设置最大等待上限（如 5s），防止单次重试耗时过长
封装成可复用的异步重试工具
把重试逻辑从业务代码中抽离，既减少重复，也提升可测性和一致性。推荐两种常用方式：
- 装饰器写法（Python）：用 @retry(max_attempts=3, backoff=True) 直接修饰 fetch 函数，内部自动处理异常与延迟
- 高阶函数写法（JS）：const safeFetch = retry(fetch, { retries: 3, minTimeout: 100 })，调用时仍保持 await safeFetch(url)
- 无论哪种，都应支持传入自定义错误过滤器和 timeout 配置
容错聚合：单点失败不影响整体结果
批量加载多个资源（如用户列表、商品详情）时，不应因某一项失败导致整个数组构建中断。
- 用 Promise.allSettled() 替代 Promise.all()，确保每项独立完成
- 对每项单独套一层重试逻辑，例如 ids.map(id => retryAsync(() => api.getUser(id)))
- 最终结果中保留成功数据，失败项可填默认值、打日志或标记为 error 状态
