async/await 与 Promise 链性能几乎无差异，本质是语法糖；性能瓶颈多源于串行 await、循环中滥用或过度 try/catch；并发请求应优先用 Promise.all，依赖顺序才用 await。
async/await 本身并不比 Promise 链更慢。它只是 Promise 的语法糖，底层执行机制完全一致，现代 JavaScript 引擎（如 V8）已深度优化，实际性能差异几乎不可测。
执行开销微乎其微
在同等逻辑下——比如连续发起两个 fetch 请求并等待响应——async/await 函数与等价的 .then() 链，运行耗时通常只差几个纳秒。这种差异对任何真实业务场景都无感知。所谓“变慢”，绝大多数源于写法不当，而非语法本身。
真正拖慢性能的常见误用
问题不在 await，而在怎么用：
- 把本可并发的请求写成串行：连续 await 三次 API 调用，总耗时≈三者相加；改用 Promise.all([...]) 后，耗时≈最长那个
- 循环中无条件 await：for (const item of list) { await fetch(item); } 会逐个阻塞，应改为 list.map(fetch) + Promise.all
- 在高频、深层嵌套场景（如万级迭代）中过度使用 try/catch：每个 await 隐含轻量 Promise 状态追踪，单次无感，但大量累积可能产生可观开销
Promise 链偶尔更合适的情况
不是所有场景都适合 async/await：
- 需要精细控制中间状态，比如 pending 时主动 abort，或插入自定义 resolve 流程
- 编写高度复用的工具函数（如 retry、timeout 包装器），直接操作 Promise 实例比包裹 async 函数更轻量
- 性能极端敏感的底层库，想避免 async 函数带来的额外闭包和上下文切换
怎么写才又快又清晰
不必非此即彼。关键是以逻辑优先：
- 有明确依赖顺序？用 await，线性表达直观可靠
- 多个独立请求？统一用 Promise.all，再 await 解构结果
- 已有 Promise 工具链（如 axios.interceptors、自定义 cancelToken）？无需强行转 async，保持一致性更重要
