async/await 与 promise 链式调用性能几乎无差异，因前者是后者的语法糖，底层均由引擎统一优化；真正影响性能的是写法：串行 await 应改用 promise.all 并发，循环中避免无脑 await，高频场景慎用过度 try/catch。
async/await 和 Promise 链式调用在性能上几乎没有差别——它们底层是同一套机制，V8 等现代引擎已深度优化，实测耗时差异通常在纳秒级，对实际应用完全无感。
async/await 本身不拖慢执行
它不是新异步模型，而是 Promise 的语法糖。编译后，await fetchData() 实际等价于 fetchData().then(...)，由引擎统一调度。所谓“变慢”，几乎全是写法问题，而非语法缺陷。
真正影响性能的常见误用
- 串行 await 替代并发：连续写三个 await，总耗时 ≈ 三者相加；改用 Promise.all([a(), b(), c()])，耗时 ≈ 最长那个。
- 循环中无脑 await：for 循环里每个 item 都 await，相当于同步阻塞执行；应改为 Promise.all(items.map(fetch)) 或分批控制并发数。
- 过度 try/catch 套 await：单个 try/catch 开销极小，但若在高频循环（如万级迭代）中每轮都包一层，微小开销会累积。
Promise 链偶尔更轻量的场景
不是语法赢了，而是控制粒度更细：
- 需要手动 abort 某个 pending 请求（如 AbortController 与 Promise 组合更直接）；
- 构建 retry、timeout 等工具函数时，直接操作 Promise 实例比包裹 async 函数少一层闭包；
- 底层库追求极致性能，避免 async 函数隐含的上下文切换和状态追踪。
怎么选才又快又稳
优先用 async/await 写业务逻辑——线性、易读、好调试；遇到明确要并发、要精细控制状态、或已在用复杂 Promise 工具链时，自然混用 Promise 链。两者不是对立关系，而是互补搭档。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
