await不阻塞线程但暂停协程，所谓“await阻塞陷阱”是误将await当并发指令导致串行执行；识别信号包括循环内逐个await、无依赖的连续await、未用Promise.all等并发方案；自检三问：是否必须等待、有无数据依赖、并发下错误处理是否可控；两个“否”即应改用并发模式。
await 本身不阻塞线程，但会暂停当前协程的执行，直到等待的 Promise（或 Future）完成。所谓“await 阻塞陷阱”，本质是误把 await 当作并发指令，结果写出串行逻辑，白白浪费异步能力。
识别串行 await 的典型信号
以下写法看似合理，实则隐含严重性能瓶颈：
- 循环中每个请求都紧跟 await：如
for (const url of urls) { const res = await fetch(url); ... } - 连续多个 await 没有提前发起：如先
await api.getUser()，再await api.getProfile()，而后者不依赖前者结果 - 函数返回前对多个独立异步调用逐个 await，未用
Promise.all或asyncio.gather
确认是否真需要串行：问三个问题
每次写 await 前快速自检：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 下一个操作是否必须等上一个结果才能开始？
- 这些异步任务之间是否存在数据依赖或状态依赖？
- 如果并发发起，错误处理、超时控制、资源限流是否仍可控？
只要答案有两个“否”，就该考虑并发方案。
用并发替代串行的常用模式
核心原则：先触发所有异步操作，再统一等待结果。
-
JavaScript：用
Promise.all([p1, p2, p3])或Promise.allSettled（容错更强） -
Python：用
asyncio.gather(coro1(), coro2(), coro3())；需不同超时或细粒度错误处理时，可用asyncio.create_task()+await -
C#：用
Task.WhenAll(task1, task2, task3)；避免在 UI 线程中调用.Result或.Wait()
警惕“伪并发”写法
有些代码表面用了并发 API，但因 await 位置不当，仍退化为串行：
- 错误：
const p1 = fetch(a); await p1; const p2 = fetch(b); await p2;—— 实际仍是先后发起 - 错误：
await Promise.all([fetch(a), fetch(b)]); await Promise.all([fetch(c), fetch(d)]);—— 两组之间串行，组内才并发 - 正确做法是把所有可并行的 Promise 提前创建好，再一次性
await Promise.all([...])
