async/await是语法糖，性能取决于promise调度、事件循环和运行环境；并行用promise.all可将串行耗时t₁+t₂优化为max(t₁,t₂)；node.js需调优内存与异步追踪；浏览器与node.js在i/o、http、gc上表现不同。
async/await 本身不提升执行速度，它只是语法糖，真正的性能取决于底层 Promise 调度、事件循环行为和运行环境配置。效率高低，关键看你怎么用，以及运行在哪种引擎或平台里。
并行 vs 串行：最直接影响耗时的写法
多个独立异步操作若串行 await，总耗时是各请求时间之和；改用 Promise.all 并行发起，总耗时接近最长那个请求。这是优化中最立竿见影的一环。
- 错误写法（串行）：
await fetch('/a'); await fetch('/b');→ 耗时 ≈ t₁ + t₂ - 正确写法（并行）：
const [a, b] = await Promise.all([fetch('/a'), fetch('/b')]);→ 耗时 ≈ max(t₁, t₂) - 注意：仅适用于无依赖关系的操作；若有顺序依赖，串行是合理且必要的
Node.js 环境下的内存与调度调优
Node.js 对长时间异步任务的资源管理较敏感。默认堆内存限制可能触发频繁 GC，尤其在高并发 Promise 链场景下。
- 可通过启动参数扩大内存上限：
node --max-old-space-size=4096 app.js（单位 MB） - 启用异步堆栈追踪：
node --async-stack-traces app.js，便于定位深层 await 带来的性能热点 - 避免在 for 循环中直接 await —— 它会隐式转为串行，批量请求应先 map 出 Promise 数组再 all
浏览器与 Node.js 的性能差异点
同一段 async/await 代码，在不同运行时表现可能不同。I/O 密集型任务在浏览器中更依赖网络栈，在 Node.js 中则受 libuv 线程池影响。
- 文件读写类操作：Node.js 的 fs.promises API 在高并发下比浏览器 FileReader 更稳定
- HTTP 请求：浏览器 fetch 天然支持连接复用与缓存策略；Node.js 需借助 axios 或 node-fetch 配置 agent 复用
- 内存回收：Node.js 中原生 async/await 的 GC 压力略低于部分封装库（如某些 polyfill 或旧版 runtime），长期运行服务建议优先用原生实现
上下文切换开销：ConfigureAwait(false) 的适用场景
这主要是 C# 场景的关键点，但在 JS 环境中也有对应逻辑——即是否需要维持执行上下文（如 UI 线程、特定 event loop phase）。JS 本身无显式上下文切换，但某些框架（如 Electron 渲染进程）存在类似约束。
- C# 中
.ConfigureAwait(false)可避免回到原始同步上下文，减少调度开销，适合后台服务逻辑 - JS 中虽无直接等价写法，但应避免在 await 后立即操作 DOM（尤其大量渲染），可考虑
queueMicrotask或setTimeout(..., 0)让出时机 - 高频调用的轻量异步函数（如配置检查），可用 memoized Promise 缓存结果，避免重复创建微任务
