接口并发增加后出现排队，团队可能尝试给数据库或 HTTP 调用套一层 Task.Run。这样并不自动减少阻塞工作，还可能让线程调度更复杂。首先要确认时间花在计算、等待还是资源争用上。
找出阻塞发生的位置
结合线程、请求耗时与依赖记录，检查同步等待异步结果、长时间锁竞争和不支持异步的调用。CPU 不高也可能有大量等待，不能仅凭 CPU 利用率判断服务器还有充足处理能力。
I/O 等待优先使用真实异步接口
沿调用链使用支持的异步方法，避免在中间层通过 Result 或 Wait 再阻塞回去。对于确实只有同步接口的库，应评估隔离、并发限制或替换，而不是无限增加工作线程。
CPU 密集任务需要容量设计
复杂计算即使换线程执行，仍然消耗 CPU。若不适合在交互请求内完成，可以评估后台任务，但需补充排队、状态和可靠性。不能把请求超时简单转成一个无法追踪的后台线程。
验收在受控并发下进行
比较排队时间、响应分布、线程数量与错误，观察压力结束后资源是否恢复。优化结论应解释消除了哪种等待，而不是仅报告某个压测峰值。
常见问题：async 方法一定不会阻塞吗？
不会自动保证。方法内部仍可能执行同步 I/O、长计算或锁等待，必须检查实际实现和依赖。
技术参考：微软：ASP.NET Core 性能实践。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。