javascript异步如何优化_async和await如何使用?

async/await 是 Promise 的封装层而非语法糖,强制将返回值包装为 Promise,throw 等价于 Promise.reject(),未 await 会导致结果丢失或异常;需合理使用 Promise.all 并发、try/catch 错误处理,并认清其仅优化控制流而非 I/O 性能。

async/await 不是语法糖,而是 Promise 的封装层

很多人以为 async/await 只是让异步写法“看起来像同步”,其实它底层强制把函数返回值包装成 Promise,哪怕你 return 42,调用方拿到的也是 Promise.resolve(42)。这意味着:如果你在 async 函数里 throw 错误,等价于 Promise.reject();如果忘了 await 一个异步调用,就等于漏掉了 Promise 链——后续逻辑可能读到 undefined 或触发未捕获异常。

常见错误现象:
- 写了 async function fetchData() { return fetch('/api'); },但调用时没 await,结果得到一个 Promise 对象而非响应体
- 在循环中直接 await apiCall(item),导致串行执行,拖慢整体耗时

  • 所有 async 函数必须用 await(或 .then())消费其返回值,否则异步结果会“丢失”
  • 不要在 for...infor...of 中无条件 await 多个独立请求——它们本可并发
  • await 只在 async 函数内有效,顶层 await 仅在 ES 模块和某些运行环境(如 Node.js 14.8+、现代浏览器模块脚本)中支持

并发请求别写成串行,用 Promise.all 替代连续 await

比如要批量获取用户信息,写成这样就是错的:

async function getUsersSequential(ids) {
  const users = [];
  for (const id of ids) {
    const res = await fetch(`/api/user/${id}`);
    users.push(await res.json());
  }
  return users;
}

每个 fetch 都得等前一个完成,总耗时 ≈ 所有请求时间之和。正确做法是先发起全部请求,再统一等待:

async function getUsersConcurrent(ids) {
  const promises = ids.map(id =>
    fetch(`/api/user/${id}`).then(r => r.json())
  );
  return Promise.all(promises);
}

注意点:
- Promise.all 一遇到 reject 就立刻失败,如果某个请求失败不想中断整体,改用 Promise.allSettled
- 如果需要带错误处理的并发,建议封装一层:const safeFetch = url => fetch(url).then(r => r.json()).catch(() => null)
- 浏览器对同一域名的并发连接数有限制(通常 6 个),超量请求会排队,不是代码问题,但需心里有数

try/catch 捕获 await 错误,但别滥用嵌套

await 后的 Promise 被 reject,会以异常形式抛出,所以必须用 try/catch 包裹,不能只靠 .catch()

错误写法:
fetch('/api').then(...).catch(...) —— 在 async 函数里混用链式写法,容易漏错误分支
try { await fetch(...) } catch(e) { ... } —— 正确,但若多处 await,别每个都套 try/catch

  • 把一组逻辑上相关的 await 放进同一个 try 块,避免重复 catch
  • 网络请求类错误建议分类处理:e instanceof TypeError(网络断开)、e.status === 401(鉴权失败)、e.name === 'AbortError'(超时取消)
  • 不要在 catch 里静默吞掉错误,至少打日志:console.error('API failed:', e)

await 无法优化 I/O 本身,只能优化控制流表达

await 不会让 HTTP 请求变快,也不会减少数据库查询次数。它只是让 JavaScript 引擎暂停当前函数执行,把控制权交还事件循环,等 Promise settle 后再恢复——这解决了回调地狱,但没解决资源瓶颈。

真正影响性能的点往往在别处:
- 接口设计是否支持批量操作(如用 /api/users?id=1,2,3 替代三次单查)
- 前端是否做了请求去重(相同参数的 fetch 是否复用缓存 Promise)
- 是否用了 AbortController 主动取消过期请求(比如用户快速切换页面时)

所以看到响应慢,先别急着改 await 写法,打开 Network 面板看实际请求耗时、状态码、响应体大小。async/await 是胶水,不是加速器。