Promise与async/await：异步编程的基础设施与语法糖深度解析

记得刚入行那年，我被一个需求折腾得够呛：三个接口，第二个要用第一个的数据，第三个要用第二个的结果。我用回调嵌套了三层，中途还有个重复用的校验逻辑。代码当时是能跑的，但两周后我自己看着那团缩进就不想动它。后来换了 Promise，再过一阵子又把业务改成 async/await 风格，整个模块才真正变得"可读、可维护"。从那之后，我对这两样东西的看法一直是：Promise 是异步编程里的基础设施，async/await 是长在这个设施上的语法层。很多人纠结它俩哪个好、哪个先进，其实对比之前得先搞清楚它俩根本不在同一个维度上。这篇文章就把我对 Promise、async 函数的理解拆开讲清楚，同时给出它们最实际的对比方式和选型判断。

1. 从回调地狱到 Promise，本质上是把一个"无法表达的过程"变成了"可表达的状态机"

1.1 回调最大的问题是它让"下一步"变得不可拆解

在 Promise 出现之前，JavaScript 里做异步操作主要靠回调函数：把"事情做完之后要执行的逻辑"作为参数传进去。这种模式在简单场景下没有任何问题：

javascript复制fs.readFile('/path/to/file', (err, data) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(data.toString());
});

一旦流程变长，问题立刻暴露。第二个请求要等第一个结果，第三个要等第二个结果，代码就会像俄罗斯套娃一层层缩进去。这种"回调地狱"不只是丑，更重要的是几个非常要命的缺陷：

第一个缺陷是流程控制被拆碎了。错误处理需要每一层都手动判断 err，稍微漏一层，异常就静默丢失。第二个缺陷是代码的执行顺序不直观，读代码的人要顺着每层回调往回推才能知道整个请求链长什么样。第三个缺陷更隐蔽：当某一段逻辑需要同时等到两个互不依赖的异步结果时，回调模式几乎没有表达力，你只能手动维护计数器。

当年我在业务代码里就用过一个非常丑陋的"双请求合并"写法：

javascript复制let userInfo = null;
let userPosts = null;
let done = 0;

function checkDone() {
  done++;
  if (done === 2) {
    renderPage(userInfo, userPosts);
  }
}

getUserInfo((data) => {
  userInfo = data;
  checkDone();
});

getUserPosts((data) => {
  userPosts = data;
  checkDone();
});

这个代码能跑，但"计数 + 判断 + 回调"这套逻辑完全靠约定，一旦某个请求失败或者回调被触发了两次，排查起来极其痛苦。本质上，回调模式缺少一个权威的、可以统一描述异步结果的结构。

1.2 Promise 引入了三种状态，异步变得可以被"观察"和"组合"

Promise 的核心贡献，是把异步操作的最终结果抽象成了一种带状态的对象。不管底层异步任务是什么——定时器、网络请求、文件读取——它最终都会坍缩为两种确定结果之一：成功（fulfilled）或失败（rejected）。在结果确定之前，它就是 pending 状态。

这种状态模型产生了两个直接影响：

一方面，异步结果不再是"回调"里那种一次性的参数传递，而是可以被存储、被传递、被监听的独立对象。你可以把一个 Promise 变量交给多个模块分别添加自己的回调，它们各自都能观察到最终结果：

javascript复制const requestPromise = fetch('/api/user');

// A 模块关心返回数据
requestPromise.then((res) => res.json()).then((data) => console.log('A: ', data));

// B 模块只关心有没有报错
requestPromise.catch((err) => reportError(err));

另一方面，Promise 天然具备组合能力。Promise.all 解决了"等所有结果"的诉求，Promise.race 解决了"取最快结果"的诉求，Promise.allSettled 解决了"不关心成败、只要全部完成"的诉求。这些都是在状态模型之上封装出来的工具方法，回调时代你想做这些事情必须手写状态管理，而 Promise 本身已经把状态管理的正确性固化在引擎层了。

我在实际开发中有一个比较深的体会：Promise 真正解决的不是"缩进问题"，而是"异步结果的可被表达性问题"。缩进问题只是表象（虽然也重要），深层问题在于回调模式没有为异步结果提供一个标准的、可操作的承载体。Promise 把这个承载体定义出来了。

2. async/await 为何能进一步降低心智负担：它把异步写成了同步的样子

2.1 async 函数的本质就是"返回 Promise 的函数"

很多初学者会误以为 async/await 是完全独立的一套异步方案，甚至觉得它比 Promise 更底层。这个方向反了。async/await 是建立在 Promise 之上的语法糖，它并没有在语言层面重新发明一种异步机制。

先看第一个基础事实：一个 async 函数，无论如何都会返回一个 Promise。哪怕函数内部写的是同步代码：

javascript复制async function foo() {
  return 42;
}

console.log(foo()); // Promise { 42 }

return 42 会被自动包装成 Promise.resolve(42)。如果函数内部抛出异常，则等价于返回一个 reject 状态的 Promise：

javascript复制async function bar() {
  throw new Error('something wrong');
}

bar().catch((err) => console.log(err.message)); // something wrong

明白这个事实之后，你会立刻意识到：async/await 与 Promise 之间不是替代关系，而是同一个机制的两个表达层次。Promise 是数据结构和执行模型，async/await 是更符合人类线性思维的语法呈现。

2.2 await 究竟"暂停"了什么：理解协程式的恢复机制

await 关键字是整个语法糖里最容易被误解的点。很多人以为它是"等待期间去干别的，等结果回来了再继续"，其实更准确的描述是：await 会把当前 async 函数的执行挂起，控制权交还给事件循环，等被等待的 Promise 落定之后，再把当前函数的剩余部分作为一个微任务重新调度执行。

来看一个最典型的例子：

javascript复制console.log('start');

async function readConfig() {
  console.log('before await');
  const data = await Promise.resolve('config done');
  console.log('after await:', data);
}

readConfig();

console.log('end');

这段代码的输出顺序是：

code复制start
before await
end
after await: config done

看到没有？readConfig() 调用之后，函数体并不是一口气跑到黑。它在 await 那一行把执行权让了出去，事件循环先处理后续的同步代码（console.log('end')），等到微任务队列轮到它了，才接着执行 await 后面的语句。

这里要专门澄清一种误区：await 不是把 JavaScript 变成了同步阻塞。当你网络请求很慢时，await 后的代码确实不会往下走，但事件循环还在正常工作，别的回调、用户事件、其他 Promise 都不会被堵死。await 只是把当前这条异步链写成了一种顺序结构的形状，并不是让 CPU 在那里干等。

为了加深理解，可以对比回调时代"等数据回来后是另外一次调用栈"这一点。Promise 时代用 .then 把下一步作为回调传入，等于把后续逻辑拆成了彼此分离的函数。async/await 则让后续逻辑还保持在同一段代码块里，变量的作用域、循环、分支都可以直接用普通语法表达。比如下面这个场景，用 .then 链来写：

javascript复制function loadDashboard() {
  return getCurrentUser()
    .then((user) => {
      return fetchUserProfile(user.id);
    })
    .then((profile) => {
      return fetchUserPosts(profile.userId, profile.page);
    })
    .then((posts) => {
      return renderDashboard(posts);
    })
    .catch((err) => {
      handleError(err);
    });
}

换成 async/await：

javascript复制async function loadDashboard() {
  try {
    const user = await getCurrentUser();
    const profile = await fetchUserProfile(user.id);
    const posts = await fetchUserPosts(profile.userId, profile.page);
    return renderDashboard(posts);
  } catch (err) {
    handleError(err);
  }
}

两段代码干的事情完全等价，但后者把"顺序依赖的异步步骤"直接还原成了自上而下的阅读顺序。JavaScript 引擎不用额外解析什么特殊语法，它只是把 await 后面的部分看作一个隐式的 .then 回调。

3. Promise 与 async/await 的真实对比：不是要选边站，而是要知道在什么层面做取舍

3.1 语法表达力对比：链式 vs 线性

很多人说的"对比 Promise 和 async/await"，实际比的是"用 .then() 链式和用 await 顺序代码写业务时的差别"。这里最重要的观察是：.then 链在表达"每一步都产生新值并传递下去"时并不差，但在表达复杂流程控制时会露出短板。

举个实际业务例子。现在有一个场景：需要拉取用户列表，再拉取每个用户的第一篇文章标题，最终输出用户和文章标题的对应关系。用 .then 链式可以这样写：

javascript复制function loadUsersWithFirstPost() {
  return fetch('/api/users')
    .then((res) => res.json())
    .then((users) => {
      const postPromises = users.map((user) =>
        fetch(`/api/users/${user.id}/posts`)
          .then((res) => res.json())
          .then((posts) => ({ user, firstPost: posts[0]?.title }))
      );
      return Promise.all(postPromises);
    });
}

用 async/await 则更贴近直觉：

javascript复制async function loadUsersWithFirstPost() {
  const res = await fetch('/api/users');
  const users = await res.json();

  const postPromises = users.map(async (user) => {
    const postRes = await fetch(`/api/users/${user.id}/posts`);
    const posts = await postRes.json();
    return { user, firstPost: posts[0]?.title };
  });

  return Promise.all(postPromises);
}

注意一个细节：后者在 map 回调里仍然用了 async 函数，同时外层还要用 Promise.all 来聚合。这说明 async/await 和 Promise 根本不是二选一的关系，它们经常需要混用。真正适合 async/await 的是有先后依赖、串行步骤明确的场景；真正适合 Promise.all 等组合器的是互不依赖、需要并行的场景。

3.2 错误处理模型对比：catch 穿透 vs try/catch 局部捕获

在 .then 链里，一个 .catch 可以捕获整条链路上任意步骤中抛出的异常：

javascript复制fetch('/api/data')
  .then((res) => {
    if (!res.ok) throw new Error(`HTTP error ${res.status}`);
    return res.json();
  })
  .then((data) => processData(data))
  .then((result) => saveResult(result))
  .catch((err) => {
    console.error('整条链上有任何一步出错都会走到这里', err);
  });

这在语义上非常像"同步代码用 try/catch 包裹大段逻辑"——任何一个环节抛错，都会跳过中间的 .then 直接落到 .catch。

async/await 的错误处理更精细：

javascript复制async function run() {
  try {
    const res = await fetch('/api/data');
    if (!res.ok) throw new Error(`HTTP error ${res.status}`);
    const data = await res.json();
    const result = processData(data);
    await saveResult(result);
  } catch (err) {
    console.error('跟 .catch 等价', err);
  }
}

从结果上看两者几乎没有差别。真正的差别在于 async/await 可以随时把 try/catch 拆分成更小的粒度。比如我只想单独保护第一个请求，后面步骤出错时希望直接抛给上层：

javascript复制async function run() {
  let data;
  try {
    const res = await fetch('/api/data');
    data = await res.json();
  } catch (err) {
    // 只处理请求阶段的错误，比如显示“网络异常，请重试”
    showToast('请求失败');
    return { success: false };
  }

  const result = processData(data); // 这里的异常不会被上面的 catch 捕获
  await saveResult(result);
}

.then 链要实现这种"分段保护"就必须在链中插入多个 .catch，但那样代码又会变得不干净，而且 .catch 之后链的返回语义容易搞混。所以我的一个经验性结论是：如果整条异步流程是一个不可分割的事务，用 .then().catch() 很清爽；如果流程里存在需要局部处理的错误分支，用 async/await 配合 try/catch 可读性好得多。

3.3 组合与并行能力对比：Promise 组合器是真正的护城河

你会发现一个事实：在表达"多个异步任务并行执行"时，async/await 本身并不提供任何新工具。它还是要用 Promise.all、Promise.race、Promise.allSettled 这些函数。更直白地说，async/await 真正擅长的是把异步流程变成"串行但可读"，而 Promise 真正擅长的是把多个独立异步结果组合成一个可等待的整体。

这里有一个非常常见的反模式：用循环命令式地等待多个互不依赖的请求完成。

javascript复制// 常见但性能差的写法
async function loadAllUsersBad(userIds) {
  const users = [];
  for (const id of userIds) {
    const res = await fetch(`/api/users/${id}`); // 串行请求
    users.push(await res.json());
  }
  return users;
}

这段代码在功能上没毛病，但性能被严重浪费了：每个请求都要等上一个请求完成才开始，总耗时是所有请求耗时的累加。正确做法是先把请求都发出去，再用 Promise.all 等结果：

javascript复制async function loadAllUsersGood(userIds) {
  const promises = userIds.map(async (id) => {
    const res = await fetch(`/api/users/${id}`);
    return res.json();
  });
  return Promise.all(promises); // 并发请求，总耗时接近最慢的那个请求
}

这个例子很好地说明了为什么我把 Promise 当作"基础设施"：真实项目里基本不可能只写单个 async 函数，也不可能有只 await 单个 Promise 的理想业务。并发、竞态、部分成功、超时——所有这些都需要框架层的能力。async/await 把"单条异步链"写得舒服，但要把"多条异步链"组织好，仍然离不开 Promise 的组合器。

3.4 执行时机与控制粒度：then 能做的事 await 不一定方便做

很多人忽略了一个 JavaScript 语言的细节：await 只能写在 async 函数内部（某些环境的顶层 await 是另外一回事）。这意味着当你有一段需要主动控制"先做一部分，等个事件，再做一部分"的动态流程时，.then 反而更灵活。举一个实际例子：一个任务队列，每个任务完成后要更新界面，失败的要重试，此时如果用 async/await 把所有过程硬写在一个函数里，循环中的错误处理会变得别扭；而用 .then 配合闭包，可以更轻量地表达"完成后自动注册下一步"。

另外注意一个微观差异：.then 可以针对同一个 Promise 注册多个回调，并且各回调之间不互相干扰。async/await 天然是"排队执行"，它本质上是把一个 Promise 的后续逻辑收敛到了一条路径上。如果一个 Promise 的结果被多处使用，用 async/await 就要重复 await 多次或者把结果存到共享变量里；而 .then 的注册模式要天然得多：

javascript复制const userPromise = fetch('/api/user').then((res) => res.json());

// 回调A
userPromise.then((user) => renderAvatar(user.avatar));

// 回调B
userPromise.then((user) => renderName(user.name));

这种"一个结果，多个观察者"的场景在事件驱动型代码里有它独特的价值。async/await 不擅长这一点，因为 await 必须占用一条执行线。

4. 几个容易混淆的细节：async 函数与 Promise 执行顺序、错误吞掉与 unhandledrejection

4.1 构造函数体与 then 回调的执行顺序差异

初学者最容易在"promise 原理"这个问题上犯迷糊。一个 Promise 构造函数里的代码是同步执行的，它并不是异步的；异步的只是 .then、.catch 里注册的回调，它们会被放进微任务队列。

javascript复制console.log('script start');

const p = new Promise((resolve) => {
  console.log('promise constructor');
  resolve('done');
});

p.then((val) => console.log('then callback', val));

console.log('script end');

输出顺序是：

code复制script start
promise constructor
script end
then callback done

也就是说，Promise 构造函数里写的 console.log('promise constructor') 跟普通同步代码没有区别，它是被立即调用的。真正排进微任务队列的是 .then 里的回调。这个知识对我们理解 async/await 也很关键：

javascript复制async function test() {
  console.log('async start');
  const val = await Promise.resolve('result');
  console.log('async end', val);
}

console.log('sync start');
test();
console.log('sync end');

输出是：

code复制sync start
async start
sync end
async end result

注意 async start 会立即打印，因为 async 函数体在没有遇到 await 之前就是普通同步执行，直到 await 才把后面的语句挂起成微任务。这个"同步开头，异步结尾"的特点，在排查 bug 时非常关键。我曾经见过一个同事在 async 函数开头写一个全局 loading 状态为 true，他以为整个 async 函数执行完才会把 loading 关掉，结果因为 await 后半段被异步调度，loading 的关闭时机完全不对。

4.2 uncaught (in promise) 是怎么产生的

热搜里有大量关键词指向一个报错：Uncaught (in promise) ...。这是前端工程和面试题都绕不过去的话题。这个报错的本质是：一个 Promise 最终进入了 rejected 状态，但代码一直没有给它注册 rejection 处理器，这个 Promise 成了一个"孤儿"。引擎不知道你是有意忽略还是忘了处理，所以它默认在全局抛出一个 Uncaught (in promise) 错误。

举一个最容易触发该问题的场景：用 fetch 请求一个不存在的接口，没有写 catch：

javascript复制fetch('/api/not-exist')
  .then((res) => res.json())
  .then((data) => render(data));
// 如果请求本身因网络或状态码进入 reject，这里没有任何 .catch，就会抛 Uncaught (in promise)

还有一个更隐蔽的场景：async 函数内部抛错，但调用方没有处理返回的 Promise，也没有 try/catch：

javascript复制async function loadData() {
  throw new Error('boom');
}

loadData(); // 这里就是 Uncaught (in promise): Error: boom

async 函数抛出的异常最终会变成一个 rejected 的 Promise，如果你不等待也不捕获，这个 rejected Promise 就会在事件循环里无人认领。

解决方式的层级也不难记：

javascript复制// 方式一：调用方用 try/catch 处理
async function handleLoad() {
  try {
    const data = await loadData();
    console.log(data);
  } catch (err) {
    console.error('捕获到了', err);
  }
}

// 方式二：调用方用 .catch 处理
loadData().catch((err) => console.error('捕获到了', err));

我在实际项目里有一个准则：凡是 async 函数被外部调用的地方，调用者必须用 await 包一层 try/catch，或者链式 .catch。否则宁可让函数内部自己完成错误处理再返回结果对象。很多线上问题都是"函数内部以为外面会处理，外面以为里面已经处理了"导致的双向甩锅。

同样值得关注的是第二种常见 Promise 报错：Uncaught (in promise) SyntaxError: "[object Object]" is not valid JSON。这个一般发生在 res.json() 时响应的内容根本不是合法 JSON。很多后端在网关报错时返回的是 HTML 或者普通文本，前端却无脑调 res.json()，于是抛出一个非常难读的报错。一个健壮的 fetch 封装通常要这样做：

javascript复制async function request(url, options = {}) {
  const res = await fetch(url, options);
  if (!res.ok) {
    // 先尝试按 JSON 解析错误信息，失败了就用状态码兜底
    let errorBody = null;
    try {
      errorBody = await res.json();
    } catch (err) {
      errorBody = { message: res.statusText };
    }
    throw new Error(errorBody.message || `HTTP ${res.status}`);
  }
  const contentType = res.headers.get('content-type') || '';
  if (contentType.includes('application/json')) {
    return res.json();
  }
  return res.text();
}

这个封装的要点在于：把状态码判断、JSON 解析的边界问题都堵住，避免 ParseError 以 Uncaught (in promise) 的形式爆发出来。

5. 进阶使用模式：Promise 与 async/await 的黄金组合

5.1 串行依赖流程 + 局部批处理

真实项目中，几乎所有核心业务逻辑都是"部分依赖、部分并行"的混合结构。以登录后初始化首页数据为例：

• 必须先拿到登录用户信息；
• 然后并行拉取用户的消息列表、订单数量、收藏夹；
• 最后把结果统一交给页面渲染。

用 Promise 组合器处理并行段，用 async/await 处理依赖段，会让整个流程干净利落：

javascript复制async function initHomePage() {
  try {
    // 第一步：串行等待登录信息
    const user = await getCurrentUser();

    // 第二步：并行拉取首页各板块数据
    const [messages, orders, favorites] = await Promise.all([
      fetchMessages(user.id),
      fetchOrderCount(user.id),
      fetchFavorites(user.id),
    ]);

    // 第三步：渲染页面
    renderHome({ user, messages, orders, favorites });
  } catch (err) {
    showErrorPage(err);
  }
}

对比之前的回调写法，这个结构几乎可以当作业务代码的标准模板来推广。

5.2 并发上限控制：Promise 组合器里隐藏的能力

有些场景你不能直接发起几十个并发请求，比如批量上传图片、批量请求用户信息。这时候如果只是把所有 fetch 塞进 Promise.all，服务端可能直接被打挂。我给项目写过一个小工具：把任意异步任务数组按并发上限分批执行，核心思路是先取前 n 个，用 Promise.race 监听完成情况，然后继续补充。

简单版实现可以这样：

javascript复制async function parallelLimit(tasks, limit = 5) {
  const results = [];
  const executing = new Set();

  for (const task of tasks) {
    const promise = Promise.resolve().then(() => task());
    results.push(promise);
    executing.add(promise);

    const clear = () => executing.delete(promise);
    promise.then(clear, clear);

    if (executing.size >= limit) {
      await Promise.race(executing);
    }
  }

  return Promise.all(results);
}

这个工具是 async/await 和 Promise 协同的典型示例：async 函数体用来控制循环节奏，Promise.race 用来感知"至少有一个任务完成了"，Promise.all 用来收集最终结果。离开任何一层，代码都会变复杂。

5.3 请求超时与取消的兜底策略

在浏览器端，取消一个 fetch 请求通常用 AbortController。但真正的超时控制，往往需要手动封装。这里也有一个 Promise/async/await 协作的标准姿势：

javascript复制function withTimeout(promise, ms) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => {
      reject(new Error(`Timeout: exceeded ${ms}ms`));
    }, ms);

    promise.then(
      (value) => {
        clearTimeout(timer);
        resolve(value);
      },
      (err) => {
        clearTimeout(timer);
        reject(err);
      }
    );
  });
}

async function loadUserWithTimeout(userId) {
  const user = await withTimeout(fetch(`/api/users/${userId}`).then((r) => r.json()), 5000);
  return user;
}

可以看到，在需要极致的时序控制能力时，底层还是要显式 new Promise。async/await 在这里扮演的只是最外层表达的角色。这进一步验证了我对两者的分层认知：Promise 是发动机，async/await 是方向盘。发动机决定动力与扭矩控制能力，方向盘决定好不好开。

6. 从工程视角看选型：哪种代码风格更该被团队推推广

6.1 我个人的默认选择：新代码优先 async/await，但在边界场景主动退回 Promise

和很多技术判断一样，我不主张"只用一个"的极端策略。我给团队定的代码规范里明确写过一条：默认情况下，新增逻辑以 async/await 为主要表达风格，尤其是存在明确串行依赖的流程；但遇到并发分组、竞态、超时、事件监听等多个 Promise 需要聚合或动态注册时，直接使用 Promise 组合器与构造函数，不必强行包一层 async 函数。

理由是：async/await 的线性表达对普通业务开发的阅读门槛最低，代码 review 的时候也更容易发现问题；Promise 的组合器在表达并发时则无可替代，强行用 async/await 去模拟反而绕远路。

举一个团队里经常出现的"错误示范"：

javascript复制// 反模式：明明可以并行，却为了统一风格串行 await
async function loadUserData(userId) {
  const user = await getUser(userId);
  const orders = await getOrders(userId); // 这里不依赖 user，完全可以并行
  const profile = await getProfile(userId); // 这里也不依赖 user
  return { user, orders, profile };
}

这种代码我看过非常多。它的正确改法是把互不依赖的请求放进 Promise.all。

6.2 可读性与调试成本：async 函数的堆栈信息值得注意

还有一个很实际的工程维度：异常堆栈的可读性。在处理多个异步阶段时，传统 Promise 链偶尔会产生比较难读的堆栈，因为每个 .then 都是独立回调，V8 引擎虽然已经做了大量优化，但有些场景下"错误从哪儿来"还是不够直观。async/await 因为在代码结构上是线性的，抛错位置的堆栈信息通常表现得更符合直觉。

javascript复制async function step1() {
  await delay(100);
  throw new Error('step1 failed');
}

async function step2() {
  await delay(50);
  return step1();
}

async function main() {
  await step2();
}

main().catch((err) => {
  console.error(err.stack);
});

如果你用的是现代浏览器或 Node.js 当前版本，堆栈里往往能完整保留 main -> step2 -> step1 的调用链，这对定位线上问题帮助很大。

6.3 给面试者和学习者的一点思路

如果你是在准备面试，或者想要把这两块基础打扎实，建议按这样一个思路梳理：

1. 先弄懂微任务机制：setTimeout、Promise.then、await 之后的代码执行顺序。
2. 自己动手模拟实现一个简化版 Promise，明白 resolve、reject、then、状态流转到底在干什么。
3. 找出三四段真实业务场景，分别用回调、Promise、async/await 三版实现，再认真对比可读性差异。
4. 刻意练习 Promise 组合器的用法：Promise.all、Promise.allSettled、Promise.race、Promise.any，连手写一个 parallelLimit 这类小工具。
5. 最后系统性整理一份"所有会导致 Uncaught (in promise) 的写法清单"，以及对应的修复模式。

我自己就曾经在面试中让候选人现场实现"串行请求数组、但允许前一个的响应作为后一个的入参"这种小需求。若他只用 Promise 链写，我会继续问怎么嵌套分支；若他能主动用 async/await 写出循环版本，再补问一遍循环内 await 的串行开销问题——能意识到用户数据要并发取、流程依赖要串行等的候选人，工程基础基本就不会差。

回到开头那个观点，Promise 和 async/await 不是对手，而是同一套异步思想在不同抽象层级上的两个产物。理解 Promise，是你理解事件循环、微任务、任务调度的一把钥匙；熟练 async/await，是你写出可维护、可读、不易错代码的捷径。两者之间的"对比"，最正确的落点不是分高下，而是明确各自的最佳适用面，让每一行异步代码都出现在它最该出现的位置上。