async/await 本身无显著性能损耗，其与 promise 链执行效率几乎一致；真正影响性能的是异步逻辑组织方式，如滥用 await 导致串行化、循环中无条件 await 等。
async/await 本身不带来显著性能损耗，它和 Promise 链在底层执行效率几乎一致——因为 async/await 就是 Promise 的语法糖，编译后最终由 JavaScript 引擎（如 V8）以相同机制处理。真正影响性能的，不是写法本身，而是你如何组织异步逻辑。
执行开销微乎其微
V8 等现代引擎对 async/await 做了深度优化。实测表明，在同等逻辑下（比如串行调用两个 fetch），async/await 函数与等价的 .then() 链耗时差异通常在纳秒级，对实际应用无感知。所谓“变慢”，多源于开发者误用，而非语法缺陷。
真正拖慢性能的常见写法
- 滥用 await 导致串行化：明明可以并发的请求，却一个接一个 await，白白增加总耗时。例如连续 await 三次 API 调用，耗时 ≈ 三者之和；而用 Promise.all 并发，耗时 ≈ 最长那个。
- 在循环中无条件 await：for (const item of list) { await fetch(item); } 会彻底阻塞后续迭代。应改用 Promise.all(list.map(fetch)) 或分批控制。
- 过度嵌套 try/catch：每个 await 行为都隐含微小的 Promise 构造与状态追踪开销，但只有在高频、深层嵌套（如万级迭代）时才可能积累出可观影响。
什么时候 Promise 链反而更高效？
极少数场景下，手写 Promise 链可能略占优势：
- 需要精细控制中间状态（如 pending 时提前 abort、或插入自定义 resolve 流程）；
- 构建高度复用的工具函数（如 retry、timeout 包装器），直接操作 Promise 实例比包裹 async 函数更轻量；
- 在性能敏感的底层库中，避免 async 函数带来的额外闭包和上下文切换。
怎么写才又快又清晰？
不必在 Promise 和 async/await 之间二选一。实践中推荐混合使用：
- 对外接口、业务逻辑层用 async/await —— 可读性高、错误处理直观；
- 内部工具方法、并发控制用 Promise.all、Promise.race 等原语 —— 明确表达并行意图；
- 遇到依赖关系时，优先让 await 自然表达顺序，而不是硬拆成 .then 链。
不复杂但容易忽略：性能瓶颈从来不在 await 关键字上，而在异步任务的设计模式里。
