Promise 从入门到进阶：状态机、链式调用、微任务与实战避坑

先抛个问题：你写前端代码的时候，有没有遇到过那种“三层回调嵌套”的代码？我实习那会儿接手过一个老管理系统，用户登录后要查角色、查菜单、再查详情，三层接口依次调用，缩进层层叠叠，每次看代码都像在解一团毛线。后来项目开始用 ES6，我才算真正体会到 Promise 带来的改变。

Promise 是什么？简单说，它就是一个“承诺”：承诺未来某个时刻给你一个结果。对应到代码里，它是一个专门管理异步操作的对象，用来替代传统回调函数。对于任何写 JavaScript 的人来讲，Promise 都不是可选项，而是绕不开的基础能力。这篇文章我会从“为什么要用”讲到“怎么用好”，再把实际项目中踩过的坑、排查过的诡异错误一并整理出来，希望能帮你少走弯路。

1. 为什么需要 Promise：回调地狱与异步控制权的回归

1.1 回调方式的三个核心痛点

在 Promise 出现之前，异步主流方式就是传回调。代码大概长这样：

javascript复制getUserInfo(function(user) {
  getRoles(user.id, function(roles) {
    getMenus(roles[0].id, function(menus) {
      render(menus);
    });
  });
});

这是经典嵌套回调的样子。我数一下，这里已经有三层缩进，业务稍微复杂一点，五层六层都不稀奇。回调方式的问题可以总结成三点。

第一，代码结构是“横向增长”的。每增加一个异步步骤就多一层缩进，一个屏幕根本装不下。维护的时候要不停展开、折叠，心智负担极重，一不小心还会漏看某个分支。第二，错误处理被切碎了。每个异步函数都有一套自己的错误回调，常见的有 Node 风格的 (err, data) 两个参数，还有的只接受失败回调。放在同一个流程里你得分别处理，只要漏掉一个，用户看到的就是“按钮点了没反应”。第三，流程控制完全靠约定。谁来调用、什么时候调用、调用几次，全靠开发者自觉。你刚写完的东西，两个星期后回来看，都会问自己一句：“这个回调到底还会不会执行？”

1.2 Promise 把“回调”变成“状态”

Promise 的设计核心，是把异步结果变成一个可以传递、可以组合的对象。这个对象有状态，Promise 帮你保证：resolve 之后状态变成 fulfilled，reject 之后变成 rejected，而且状态一旦改变就永远固定。

开发者不再把“下一步逻辑”塞进回调里，而是把它变成 then 方法上的参数。这样带来的直接好处是：异步代码可以像同步代码一样，用“返回值”继续往下走。

javascript复制getUserInfo()
  .then(user => getRoles(user.id))
  .then(roles => getMenus(roles[0].id))
  .then(menus => render(menus))
  .catch(err => console.error(err));

同样是三层依赖，结构从嵌套变成了平铺的链。每一行只管“拿到上一步的结果，处理，然后返回给下一步”。不需要再关心回调什么时候触发，只需要关注这条链上的每个环节。这个改变看似不大，但对复杂流程的可维护性提升是质的。这也是为什么后来 async/await 能这么流行——底层依然是这套“状态机”机制。

2. Promise 核心机制：状态机与链式调用

2.1 三个状态与不可逆

Promise 只有三个状态：pending（进行中）、fulfilled（已成功）、rejected（已失败）。pending 是初始状态，最终只能变为 fulfilled 或 rejected。

这个设计想表达什么？用生活里的例子来说，Promise 就像一个外卖订单。下单之后是 pending，骑手送达是 fulfilled，等了半小时告诉你商家没货，那就是 rejected。关键点在于：一旦送达，就不会变成没货；一旦没货，也不会迟到送达。状态只能是二选一。

写代码的时候经常有人犯一个错：在异步回调里调用了两次 resolve。比如：

javascript复制const p = new Promise((resolve, reject) => {
  fs.readFile('a.txt', (err, data) => {
    resolve(data);
    resolve(data + 'again'); // 无效，第一次 resolve 之后状态已经固定
  });
});

第二次 resolve 完全静默无效，不会抛错也不会影响结果。它的意义在于，Promise 的所有下游 then 回调只会执行一次，不会出现“同一个请求的数据被渲染两遍”这种错乱。

再补充一个细节：new Promise((resolve, reject) => {...}) 的执行器函数是同步执行的。也就是说，里面如果有 console.log，会在 Promise 创建那一刻立刻打印，而不是等异步结束。这个特性在后面排查执行顺序问题时很有用。

2.2 resolve 的参数可能是另一个 Promise

这是很多面试爱考、但日常容易忽略的细节。resolve 接受一个 Promise（或者任何带 then 方法的对象，也叫 thenable）时，外层 Promise 会选择“跟随”这个 Promise 的状态。举个例子：

javascript复制const p1 = new Promise(resolve => setTimeout(() => resolve('ok'), 1000));
const p2 = new Promise(resolve => resolve(p1));

p2.then(value => console.log(value)); // 1秒后打印 ok

p2 resolve 了 p1，它并不会立刻变成 fulfilled，而是等 p1 落定之后，把 p1 的结果透传出来。这个机制在后面讲深拷贝和 thenable 的时候还会用到，先记在心里。

2.3 then 的返回：每次都生成一个新 Promise

then 方法有两个参数：onFulfilled 和 onRejected。但最关键的是，调用 then 之后会返回一个全新的 Promise。这个 Promise 的状态取决于 onFulfilled 的返回值：

• 返回普通值，新 Promise resolve 这个值
• 返回一个 Promise，新 Promise 跟随它
• 什么都不返回（返回 undefined），新 Promise resolve undefined
• 抛异常，新 Promise reject

这个机制决定了链式调用的正确姿势。很多人写链式调用时会在 then 里 new 一个 Promise 却不 return，这是最常见、也是伤害最大的错误之一：

javascript复制// 错误示范
getUser()
  .then(user => {
    new Promise(resolve => resolve('xxx')); // 没有 return！
  })
  .then(value => {
    console.log(value); // 打印 undefined
  });

因为没有 return，第二个 then 拿到的就是 undefined。控制权脱节了，整个链等于断掉。正确写法是：

javascript复制getUser()
  .then(user => new Promise(resolve => resolve('xxx')))
  .then(value => console.log(value)); // xxx

这条规则延伸到 async/await 里也成立：async 函数里的 return 值，本质就是 resolve 的结果；里边抛出的异常，外层就是 reject。

2.4 catch 什么时候能接到错误

Promise 的错误处理比较特殊：catch 只能捕获链上“前置环节”抛出的错误，而且如果链上某个 then 里抛出了新的错误，后面的 catch 也会收到。这是因为链上每一步返回的都是新 Promise，错误会沿着链传递下去。

但有一个非常隐蔽的坑：在 Promise 的执行器里，代码是同步执行的，如果执行器本身抛异常，Promise 会自动 reject，所以 catch 能接住。但是在异步回调里再抛异常，情况就不同了：

javascript复制const p = new Promise((resolve) => {
  fs.readFile('a.txt', (err, data) => {
    throw new Error('异步回调里的异常'); // 这个异常发生在读取文件的回调里，Promise 不知道
  });
});

这个异常不会自动变成 rejected，Promise 会一直 pending，永远不会落定。处理办法是在异步回调内先判断错误，手动调用 reject(err)，或者在最外层补一个全局 unhandledrejection 监听作为兜底。凡是涉及 Node 的 fs、回调风格的接口，这条经验都非常实用。

3. 实操：在真实业务里落地 Promise

3.1 封装一个带超时的请求层

讲 Promise，最好的方式还是拿真实项目里能直接用的封装来拆解。比如前端开发里，需要把所有接口请求统一到同一个入口，方便做鉴权、做错误提示。用 Promise 包装一个请求函数很典型：

javascript复制function request(url, options = {}) {
  return new Promise((resolve, reject) => {
    if (!navigator.onLine) {
      reject(new Error('网络已断开'));
      return;
    }
    fetch(url, options)
      .then(res => {
        if (res.ok) return res.json();
        reject(new Error(`HTTP ${res.status}`));
      })
      .then(data => resolve(data))
      .catch(err => reject(err));
  });
}

这个封装把成功路径统一到 resolve，失败路径统一到 reject。调用方根本不用关心 fn 内部是 fetch、XMLHttpRequest 还是别的什么异步库，只需要在 then 里拿结果、在 catch 里处理错误。

配合超时保护也很简单，用 Promise.race 实现一个 withTimeout：

javascript复制function withTimeout(promise, ms) {
  return Promise.race([
    promise,
    new Promise((_, reject) => setTimeout(() => reject(new Error('请求超时')), ms))
  ]);
}

const api = withTimeout(request('/api/user'), 5000);
api.then(render).catch(err => toast(err.message));

这是我项目里用得非常频繁的组合。核心思路是让“超时”本身也变成一个“失败”，这样所有异常处理都收敛到一个 catch，不需要在业务代码里到处写 if (err.message === '请求超时') 这样的判断。

3.2 Promise.all 处理并行请求

业务里经常遇到“等两个接口都返回再渲染”的场景。这时候用 Promise.all：

javascript复制const userPromise = request('/api/user');
const menuPromise = request('/api/menu');

Promise.all([userPromise, menuPromise])
  .then(([user, menu]) => render(user, menu))
  .catch(err => console.error(err));

Promise.all 的特点是“全成功才成功，一个失败就失败”。它内部会等所有数组元素都落定，如果其中任何一个 reject，整个 Promise 立即变成 rejected，其它请求虽然还在跑，但结果已经不会被处理。这在有些业务上会显得浪费，比如两个请求里挂了一个，另一个其实还有用。

这时候可以用 allSettled：

javascript复制Promise.allSettled([
  request('/api/part1'),
  request('/api/part2'),
]).then(results => {
  results.forEach((result, index) => {
    if (result.status === 'fulfilled') {
      console.log('部分数据', index, result.value);
    } else {
      console.warn('失败', index, result.reason);
    }
  });
});

allSettled 在 ES2020 进入标准，现代浏览器和 Node.js 12+ 都支持，已经不需要再考虑兼容问题了。它的价值在于：你关心的是“每个请求最终的状态”，而不是“所有请求必须全成功”。比如一个仪表盘页面，左边数据挂了右边还能显示，这种场景就应该选 allSettled 而不是 all。

3.3 Promise.race 与 Promise.any：两种“抢先”语义

提到 race，大家第一反应是超时控制。其实 race 还能做“切换最快的来源”。比如并发请求多个 CDN，哪个先回来用哪个：

javascript复制const cdn1 = request('https://cdn1.example.com/resource');
const cdn2 = request('https://cdn2.example.com/resource');
Promise.race([cdn1, cdn2]).then(res => render(res));

race 返回的是“第一个落定”的 Promise 的结果，不管它是 fulfilled 还是 rejected。这意味着如果最快的那个请求失败了，race 也直接失败，不会等其它成功的请求。用它做资源竞争时要小心这一点：可能最快的那条请求恰好是个失败，明明慢一点的成功结果反而被丢掉了。

如果想“第一个成功的结果优先”，这个语义用 Promise.any 更合适：

javascript复制Promise.any([
  request('https://cdn1.example.com/resource'),
  request('https://cdn2.example.com/resource'),
]).then(res => render(res));

any 的行为是：只要有一个 fulfilled，整个 Promise 就 fulfilled；如果全部 rejected，最终 reject 一个 AggregateError。团队里新人在做“多源容灾”时经常把 race 和 any 混用，我一般会提醒一句：你想要“最先完成的”，选 race；你想要“只要能成功就行”，选 any。

还有一个容易被忽略的边界：Promise.all 对空数组立即返回已 resolved 的 Promise，而 Promise.race 对空数组返回的 Promise 会永远停留在 pending 状态。写通用封装的时候记得对数组做空值判断，避免出现“根本没有任务，却永远等待”的情况。

3.4 用 async/await 重写链式代码

async/await 不是 Promise 的替代品，而是 Promise 的语法糖。async 函数永远返回一个 Promise，await 后面可以接任意值：普通值直接作为结果，Promise 就等待其落定。

javascript复制async function loadPage() {
  try {
    const user = await request('/api/user');
    const menus = await request(`/api/menu?userId=${user.id}`);
    render(user, menus);
  } catch (err) {
    toast(err.message);
  }
}

这个写法的最大好处，是把链重新拉回我们最熟悉的顺序代码。代码看起来像同步，实际上依然是异步。很多从传统后端转过来的同事说，看懂 async/await 之后，才算真正理解 Promise 的价值。

需要留意的是，await 只能在 async 函数内使用。如果你在普通函数里写 await，会直接语法报错。而且 async 函数里的 try/catch 作用范围很清晰：它能够捕获 await 等待过程中发生的拒绝，以及 await 之后同步代码抛出的异常——因为整个函数本身就是一个 Promise，任何异常都会变成该 Promise 的 rejection，最终被 catch 接收。

4. 细节进阶：微任务、事件循环与 Promise 的时序

4.1 微任务队列的顺序

这一节如果不想被面试官问倒，或者说想在疑难 bug 面前有点排查思路，值得认真读。Promise 的 then 回调不是同步执行的，也不会像 setTimeout 一样进宏任务队列，它进入的是微任务队列。

微任务队列的特点是：在当前宏任务结束之后、下一个宏任务开始之前，清空整个微任务队列。举个例子：

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

setTimeout(() => console.log('timeout'));

Promise.resolve().then(() => console.log('promise'));

console.log('end');

输出顺序是：start、end、promise、timeout。原因是同步代码先执行完，然后微任务（promise）在宏任务（timeout）之前执行。你可以把这个顺序理解为：微任务永远插在“当前这段同步代码”和“下一个宏任务”之间。

同一队列里多个 Promise 则按入队顺序依次执行。这个特性在写业务时影响可能不大，但在写“基于 Promise 的调度器”“异步队列”这类基础设施时特别重要。比如要实现一个 sleep 函数：

javascript复制const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

如果连续 await 两个 sleep(0)，它们的表现和双层 setTimeout(0) 会有差异，因为 await 不仅等宏任务，还需要微任务排空。理解这一点之后，调试“明明改了状态但页面没马上刷新”这类问题，你的排查思路会清晰很多：先确认数据是否真的更新，再看更新动作落在了哪个任务队列。

4.2 初始化 Promise 时的重要细节

一个容易误会的点：new Promise 的执行器是同步执行的，所以用它来包一个第三方库调用时要小心性能。比如：

javascript复制const p = new Promise((resolve) => {
  heavySyncWork(); // 这里会同步阻塞主线程
  resolve(heavySyncWorkResult);
});

这个 heavySyncWork 会立刻执行并阻塞主线程，之后 p 才会进入 fulfilled。有些同学以为 Promise 包一层就“异步”了，其实完全不是。如果真的想让某段同步计算不阻塞渲染，需要自己调度到宏任务或者分批处理，Promise 本身做不到“推迟到未来”。

反过来，如果你只想“在当前代码之后执行某段逻辑”，又不想用 setTimeout，可以用：

javascript复制Promise.resolve().then(() => console.log('微任务里执行'));

这个模式在 Vue 的 nextTick 实现、部分框架的异步更新调度中非常常见，本质就是 Promise 微任务特性的应用。

4.3 async 函数内部的执行顺序

还有一个容易被忽略的点：async 函数在没有 await 的部分，是同步执行的。只有碰到第一个 await 才开始挂起：

javascript复制async function test() {
  console.log('a');
  await Promise.resolve();
  console.log('b');
}

test();
console.log('c');
// 输出：a、c、b

很多人以为 async 函数整体是异步的，其实只有 await 之后的代码才被放到微任务队列。这也是为什么某个 async 函数第一行就 console.log，会在同步代码之前打印出来。这个特性在排查“函数调用顺序打印异常”的时候特别有启发。

5. 极容易被忽略的坑：深拷贝与 Promise 相遇

5.1 深拷贝时 Promise 字段为什么会丢

这个点搜索热度很高，我也踩过。业务里有这么个场景：接口返回的数据带一个缓存 Promise，前端需要把整包数据做一次深拷贝，再塞到状态管理里。用最经典的 JSON 深拷贝：

javascript复制const data = {
  id: 1,
  cachePromise: Promise.resolve('cached')
};
const copy = JSON.parse(JSON.stringify(data));
console.log(copy.cachePromise); // {}

Promise 被序列化成空对象。原因很简单：JSON.stringify 只会序列化可枚举的字符串键属性，Promise 实例没有任何可枚举的自有属性，序列化结果自然是 {}。如果 Promise 里加载的数据又很大，这种方式还会悄悄丢掉大量信息。

正确做法是，在拷贝前识别 Promise 实例，保留引用。因为 Promise 的状态已经固定，深拷贝出一个“状态副本”没有实际意义，而且也不可能拷贝出正在等待的结果。一个简单的深拷贝函数可以这样写：

javascript复制function deepCloneWithPromise(source, map = new WeakMap()) {
  if (source === null || typeof source !== 'object') return source;
  if (map.has(source)) return map.get(source);

  const result = Array.isArray(source) ? [] : {};
  map.set(source, result);

  if (source instanceof Promise) {
    // Promise 状态不可变，直接保留原引用
    return source;
  }

  for (const key of Object.keys(source)) {
    result[key] = deepCloneWithPromise(source[key], map);
  }
  return result;
}

如果业务上确实需要一个“全新的 Promise”，正确做法不是拷贝实例，而是保存“产生 Promise 的函数”，在需要时重新执行该函数。

5.2 thenable 引发的解析陷阱

前面提到，resolve 一个 Promise 会“跟随”它。如果某个对象碰巧带 then 方法，它也会被当作 thenable 处理：

javascript复制const thenable = {
  then(resolve) {
    resolve('thenable 被展开了');
  }
};

Promise.resolve(thenable).then(value => console.log(value));
// 输出：thenable 被展开了

因为 Promise.resolve 会尝试展开 thenable。于是问题来了：深拷贝一个对象时，如果被拷贝的对象恰好有一个“看起来像 then 方法”的属性，你在拷贝过程中用 Promise.resolve(item) 包一层，就可能意外触发它的执行。这在真实开发中并不算高频，但如果你的网关层、SDK 或者代理层某个对象带了 then 方法，链路会变得很诡异：明明没有任何 Promise 相关调用，却冒出一个永不落定的 pending。

规避方式很简单：在 Promise.resolve 之前明确排除业务数据中的裸 then 方法，常见做法是用 value instanceof Promise 判断后再决定是否包 Promise。很多第三方库的数据实体容易携带这类方法，踩过的人才知道有多痛。

5.3 如何判断一个 Promise 是否已经落定

Promise 没有暴露同步查询状态的 API，你不能直接写 promise.status === 'fulfilled'。但在调试过程中，“判断这个 Promise 是否已经在某个时间点落定”是一种很常见的需求。

可以用一个超时判断工具：

javascript复制function isPromiseSettled(promise, timeout = 0) {
  const flag = Symbol('settled');
  return Promise.race([
    promise.then(() => flag, () => flag),
    new Promise(resolve => setTimeout(resolve, timeout))
  ]).then(result => result === flag);
}

这个封装可以判断某个 Promise 在 timeout 毫秒内是否会落定，本质上还是用了 race。注意 timeout 为 0 时也不会立刻同步判断，它仍然经过一次微任务调度，所以做不到“纯同步判断”。用它做诊断逻辑没问题，但不要把它当成同步 API 来依赖。

6. 常见问题排查与独家避坑心得

6.1 “Uncaught (in promise)”到底在说什么

控制台最常见的报错之一，就是 Uncaught (in promise) Error: xxx。这句话的意思是：某个 Promise 被 reject 了，但链上没有任何 catch 去接住，于是错误上抛到全局。默认行为是打印到控制台，如果发生在浏览器扩展、Node 进程里，还可能触发 unhandledrejection 或 uncaughtException。

最直接的场景是这样。你的 Promise 的 rejection 没有处理，或者是在 async 函数里抛了异常，但没有被 try/catch 或外层 .catch 接住：

javascript复制async function load() {
  throw new Error('boom');
}
load(); // Uncaught (in promise) Error: boom

处理方式很简单。给调用方补 catch：

javascript复制load().catch(err => console.error('已处理', err));

或者在 async 函数内部用 try/catch。更保险的是在全局挂一个兜底监听：

javascript复制window.addEventListener('unhandledrejection', (event) => {
  console.warn('未处理的 Promise 拒绝', event.reason);
  event.preventDefault();
});

兜底只是日志，别指望它替代业务上的错误处理。真正要做的是建立“凡是异步操作，都必须有失败路径”的代码习惯。我团队里现在推行一条铁律：每个返回 Promise 的函数，必须明确它的 reject 条件；每个调用它的地方，必须明确要不要处理错误。可以决定不处理，但必须是想过之后的不处理，而不是依赖控制台报错再回头补。

6.2 事件监听器返回 Promise 引发的“异步响应”问题

某次排查一个 Chome 相关的工程时，控制台报出这么一条：

code复制Uncaught (in promise) Error: A listener indicated an asynchronous response by returning true, but the promise never resolved

这串英文第一次见的人多半一脸懵。翻译过来是：监听器通过返回 true 表示“我会异步响应”，但它返回的 Promise 一直没落定。

这个场景一般出现在扩展机制里，或者在框架事件系统中使用了 async 监听器，但没有正确返回标志的情况。核心机制是：事件系统询问监听器“你能异步处理吗？”监听器返回 true 表示可以；系统随后等待监听器完成异步响应。结果你的监听函数是 async 的，函数执行中抛了异常，这个异常变成一个 rejected 的 Promise，而没有任何代码去 catch 它，系统等待的那个 Promise 永远没进入 settled 状态，于是它自己又补报了一条。

其实修复思路不算复杂。先把监听器里的异常捕获掉，确保无论成功还是失败，都明确地发送响应。比如扩展场景里，正确写法之一是：

javascript复制chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
  if (msg.type === 'do') {
    process(msg).then(
      result => sendResponse({ ok: true, result }),
      err => sendResponse({ ok: false, error: err.message })
    );
    return true; // 明确告诉系统：我会异步地调用 sendResponse
  }
  sendResponse({ ok: false });
});

在这种写法里，监听器本身不是 async，它通过返回 true 表示“这个响应是异步的”，随后在 Promise 的 then 里调用 sendResponse。这样 Promise 即使 reject，也会被第二个参数处理掉，不会再冒出 Uncaught (in promise)。

这种“返回 true 表示异步响应”的机制，在很多框架事件系统里都有类似设计。排查思路其实就两条：一是确认监听器返回的值是否符合事件系统对“异步标志”的约定，二是确认监听器内部产生的 Promise 必须被处理，绝对不能让它裸着 reject。

6.3 排查 Promise 问题时我常用的三个方法

第一个方法是“分段拆”。把长链拆开，每段 then 都放到独立函数里，打印它拿到和返回的值：

javascript复制const step1 = () => request('/api/user').then(data => {
  console.log('user', data);
  return data;
});
const step2 = (user) => request(`/api/menu?uid=${user.id}`).then(data => {
  console.log('menu', data);
  return data;
});

step1().then(step2).then(render);

好处是错误栈相对干净，能快速定位断在哪一步。第二个方法是“加尾兜”。把所有最终链都补一个 catch，哪怕只是为了打日志：

javascript复制Promise.resolve()
  .then(() => { throw new Error('x'); })
  .catch(err => console.error('链上错误', err))
  .finally(() => console.log('无论如何都会执行'));

finally 是 ES2018 加入的，无论成功失败都会执行，很适合做 loading 关闭、日志埋点这类收尾逻辑。第三个方法是注意“新建与复用”。同一个 Promise 引用多次 then，得到的是多个互不干扰的分支：

javascript复制const p = Promise.resolve('数据');
p.then(v => console.log('分支1', v));
p.then(v => console.log('分支2', v));

这种写法是允许的，但要注意它不等于链式传递。如果你期望第二次 then 拿到的是第一次 then 处理后的结果，那一定要链式串联，而不是各自挂分支。

6.4 Promise 反模式速查清单

根据我日常 review 代码时见过的各种问题，整理了一份快速自查清单，你可以直接抄：

这份清单是无数次 review 和线上问题换来的。绝大部分异步 bug 都不是 Promise 本身复杂，而是“约定”没做好：返回没写清、失败路径没覆盖、状态理解出错。把清单过一遍，至少能挡掉线上八成以上的异步问题。

最后分享一点个人体会。刚接触 Promise 的时候，我和很多人一样，把它当成“让代码不那么嵌套的语法糖”。直到后来维护一个几十万行的老系统，把几百处回调重构成 Promise 链，又再演进到 async/await，才真正理解：Promise 带来的不只是语法好看，而是一种“显式的异步契约”。每个操作都摆明了会不会失败、成功了拿到什么、失败了怎么处理。这种确定性，才是它最值钱的地方。

如果你正在学习或者重构，建议先从一条链路练起，把已有回调改成 Promise 链，再加上超时与兜底，然后再尝试 async/await。踩过几个坑之后，你一定会比别人更快摸清这套机制的脾气。