async/await 本身无性能开销，性能瓶颈源于微任务调度；优化关键在于减少不必要的微任务排队：避免循环中逐个 await，改用 Promise.all 并发；控制并发数应使用 p-limit 而非 await 限流；扁平化 await 链、慎用 try/catch、缓存 Promise 实例以降低重复调度。
async/await 本身不产生“性能开销”，它只是 Promise 的语法糖；真正影响性能的是 await 触发的微任务调度行为。微任务虽轻量，但大量、高频或不当嵌套时，会加剧事件循环负担，拖慢响应、增加内存压力，甚至引发堆栈追踪混乱。优化重点不是去掉 async/await，而是减少不必要的微任务排队和调度延迟。
避免在循环中无节制使用 await
for 循环里逐个 await，本质是把 n 个异步操作串成一条微任务链，每轮都得等前一个 Promise settle 后再注册下一个——这不仅耗时，还放大了微任务队列长度。
- ❌ 错误写法（顺序 + 高微任务密度）：
for (const id of ids) { await fetchUser(id); } - ✅ 正确做法：用 Promise.all 并发发起请求，只产生 1 次微任务等待点
await Promise.all(ids.map(fetchUser)); - ⚠️ 注意：若需控制并发数（如防请求打爆后端），用 p-limit 或手写信号量，而非靠 await 限流——后者只是假性“节流”，实际仍压满微任务队列
减少 await 表达式的嵌套层级
深层 await 链（比如 await fn1().then(() => await fn2())）会导致微任务层层嵌套，Chrome DevTools 的 async stack trace 可能断裂，定位困难；V8 也难以对过深调用做内联优化。
- 尽量扁平化逻辑：把多层 await 拆到同一级作用域中并行处理
- 避免在 .then() / .catch() 回调里再写 await —— 这会额外插入微任务，不如统一用 async 函数封装
- 示例：
async function loadAll() {
const [a, b] = await Promise.all([fetchA(), fetchB()]);
return { a, b };
}
慎用 try/catch 包裹每个 await
V8 引擎在有 try/catch 的 async 函数中会禁用部分优化（如内联缓存），尤其在高频调用场景下，微任务执行效率会小幅下降。
立即学习“Java免费学习笔记（深入）”；
- 仅在确实需要捕获并处理该处异常时加 try/catch
- 对可预期失败的操作（如非关键接口），优先用 Promise.allSettled 或手动检查 .status
- 统一错误兜底更高效：
function safe(fn) { return async (...args) => { try { return [null, await fn(...args)]; } catch (e) { return [e, null]; } }; }
用惰性求值+缓存减少重复微任务注册
重复调用同一个 async 函数（如 getConfig()、getAuth()），每次都会新建 Promise 并触发新微任务。若结果短期不变，应缓存 Promise 实例本身，而非只缓存返回值。
- 用 WeakMap 或 Map 缓存 Promise，避免内存泄漏
const cache = new Map();
async function getCachedConfig() {
if (!cache.has('config')) {
cache.set('config', fetch('/config').then(r => r.json()));
}
return cache.get('config');
} - 配合 TTL 或版本号实现缓存失效，防止 stale data
