增强 async/await 抗压能力需从并发、错误、资源、上下文四方面入手：合理并行（promise.all/task.whenall）、限流（semaphoreslim/p-limit）、错误隔离（分段try/catch+降级）、减少开销（configureawait(false)/valuetask/复用客户端）。
增强 async/await 模式下异步代码的抗压能力，核心不是“写得更炫”，而是让并发、错误、资源和上下文四方面更可控、更健壮。尤其在高并发或不稳定网络环境下，简单 await 串行调用容易放大延迟、拖垮线程池、掩盖失败根源。
合理并行，避免无谓串行等待
多个独立异步操作（如查用户、拉配置、读缓存）若强行逐个 await，总耗时是各请求之和；改用并行可压缩为最长那个的耗时。
- ✅ 用 Promise.all 或 Task.WhenAll 同时发起互不依赖的请求
- ⚠️ 注意：Promise.all 任一失败即整体 reject；需容错时改用 Promise.allSettled 或 Task.WhenAll + 手动检查结果状态
- ? 避免在循环里连续 await（如 for-of 中逐条 fetch），应先收集 Promise，再统一 await
精准控制并发量，防止资源过载
面对大量并发请求（如批量处理 1000 条订单），不限流会压垮下游服务或耗尽连接池。
- ✅ 使用 SemaphoreSlim（C#） 或 p-limit（JS） 控制同时进行的请求数（如限制为 5～10）
- ✅ 对数据库或 HTTP 客户端配置连接池上限（如 HttpClient.MaxConnectionsPerServer）
- ✅ 批量操作优先走聚合接口（如 /batch/users），而非单条循环调用
错误隔离与降级，避免雪崩
一个上游异常不应导致整个链路中断，尤其在多步骤依赖场景中。
- ✅ 每个关键异步调用单独 try/catch，失败后返回默认值或触发降级逻辑（如读缓存失败则查本地兜底数据）
- ✅ 避免把所有 await 堆在一个大 try 块里——定位难、影响范围大；按业务边界分段捕获
- ✅ 对非核心依赖（如埋点上报、日志推送）使用 fire-and-forget 模式，不阻塞主流程
减少上下文开销与内存压力
高频异步调用中，状态机、同步上下文捕获、Task 对象分配都会累积性能损耗。
- ✅ 在类库或后台服务中，异步方法末尾加 .ConfigureAwait(false)（C#），避免 UI 或 ASP.NET 同步上下文切换开销
- ✅ I/O 密集场景优先用 ValueTask 替代 Task（C#），减少堆分配
- ✅ 避免在热路径上创建新对象（如每次 await 都 new HttpClient）；复用客户端实例
