await本身无性能开销，性能瓶颈在于promise是否可并行及是否必要串行；独立操作应优先用promise.all并发，避免逐个await导致总耗时累加。
async 函数中 await 的顺序执行本身不会带来额外性能开销，但它的实际性能表现取决于 await 后面的 Promise 是否可并行、是否真正需要等待、以及是否有不必要的串行化。
await 本身不耗时，耗时的是它等待的异步操作
await 是语法糖，底层基于 Promise 和微任务调度，它本身几乎不占用 CPU 时间。真正影响性能的是 await 后面那个 Promise 的执行逻辑——比如一个 HTTP 请求、数据库查询或定时器。
- 如果 await 后是
await fetch('/api/a')，耗时主要在网路往返和服务器处理 - 如果 await 后是
await Promise.resolve(1)，几乎是瞬时完成（微任务队列中立即 resolve） - await 只是让 JS 引擎暂停当前 async 函数的执行，把控制权交还给事件循环，不阻塞主线程
顺序 await 导致串行瓶颈，能并行就别串行
多个独立异步操作如果用 await 逐个写，会强制变成串行，总耗时 ≈ 各操作耗时之和；而用 Promise.all 并发发起，总耗时 ≈ 最长那个操作的耗时。
- ❌ 串行写法（慢）：
const a = await api.getA();<br>const b = await api.getB();<br>const c = await api.getC();
→ 假设每个请求 200ms，总耗时约 600ms - ✅ 并行写法（快）：
const [a, b, c] = await Promise.all([api.getA(), api.getB(), api.getC()]);
→ 同样三个请求，总耗时约 200ms（假设网络无竞争）
await 不等于“必须等前一个结束才能开始下一个”
很多人误以为 await 必须严格串行，其实只要 Promise 已经被创建（即异步操作已发起），就可以提前 await —— 关键在于“发起时机”，而非“await 时机”。
- 正确提前发起：
const p1 = api.getA(); // 立即发起<br>const p2 = api.getB(); // 立即发起<br>const a = await p1;<br>const b = await p2;
- 错误延迟发起：
const a = await api.getA(); // 等完才发起下一个<br>const b = await api.getB();
- 这种模式适合有依赖关系的操作（如 token 刷新后发请求），但无依赖时就是性能陷阱
调试与评估：用 Performance API 或浏览器 DevTools 定量看
光靠直觉容易误判，真实性能得靠工具验证：
- 在 async 函数内用
performance.mark()+performance.measure()标记各 await 区间耗时 - Chrome DevTools 的 Network 和 Performance 面板可直观看到请求是否并行、是否存在空闲间隙
- 注意：Node.js 中可用
console.time()或process.hrtime()测量，但要排除 I/O 调度干扰
关键不是避免 await，而是理解它何时引入串行等待、何时可以解耦发起与等待。合理使用 Promise.all、提前创建 Promise、拆分有无依赖的操作，比纠结 await 语法本身更能提升性能。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
