Promise与async/await异步编程

可视化演示

展示程序查询、中断驱动和DMA三种I/O控制方式的数据传输路径与CPU利用率差异，直观对比不同I/O控制策略的性能特征。

同步与异步：深夜食堂的两种经营模式

深夜食堂对面，还有一家“老王面馆”。老王是个固执的人，他坚持“同步经营”——来了第一位客人，先做他的面，做好了端上桌，再接待第二位。客人少的时候没什么，可一到夜宵高峰，队伍排到街角。最气人的是，排在后面的客人明明只想要一碗白粥，也得等前面三碗拉面全做完。这就是同步阻塞：一个任务不完成，后面的任务全部排队等待。我们的浏览器主线程也是这样——它要负责渲染页面、响应用户点击、执行JavaScript。如果某个任务耗时三秒，这期间用户点哪里都没反应，页面就像“冻住”了。

深夜食堂的老板则聪明得多。他采用“异步经营”：客人来了先记下需求、发一张小票，然后该干嘛干嘛。做面的时间用来煮汤，煮汤的间隙还能先煎个饺子。客人不用死等，可以刷手机，等菜好了小票会响。这就是异步非阻塞：耗时任务交出去，主线程继续服务其他请求。JavaScript是单线程语言，但借助事件循环（Event Loop），它能像这位老板一样“一心多用”。事件循环就像一个传菜员，它不断查看“任务队列”里有没有完成的任务，有就把对应的回调函数拿回主线程执行。

1. 同步模型：代码从上到下逐行执行，前一行没走完，后一行永远等在那里。好比客人不吃完，老板不接待下一位。

$$\text{同步执行} = \text{逐行排队}，\text{前一行阻塞} \Rightarrow \text{后一行等待}$$

2. 异步模型：耗时操作交给浏览器API处理，主线程继续执行后续代码。好比老板记下需求，转身做别的菜。

$$\text{异步执行} = \text{先注册回调}，\text{主线程不等待} \Rightarrow \text{事件完成后回调入队}$$

3. 事件循环：主线程执行完当前所有同步代码后，从任务队列取出一个回调执行。传菜员只在小票响了之后才行动。

$$\text{事件循环} = \text{执行同步栈} \rightarrow \text{取回调} \rightarrow \text{执行} \rightarrow \text{循环}$$

回到深夜食堂的比喻：同步的“老王面馆”在高峰期注定要赶走客人，而异步的“深夜食堂”能同时服务十桌客人。前端的核心体验——页面流畅不卡顿——本质上就是异步思想的胜利。理解同步和异步的区别，是你拿到“订餐小票”前的第一课。

// 同步阻塞：第一个计时器没走完，第二个根本没机会开始console.log('第一份面开始做');var start = Date.now();while (Date.now() - start < 1000) {}console.log('第一份面好了'); // 异步非阻塞：先记下需求，时间到了回调自动触发console.log('第一份面开始做');setTimeout(function() {  console.log('第一份面好了');}, 1000);console.log('可以接待第二位客人了');

Promise三状态：一张小票的三种命运

深夜食堂的小票，在不同时刻有着完全不同的状态。你刚点完菜时，小票上写着“备餐中”——这是待定状态（pending）。过一会儿，菜做好了端上桌，小票变成“已完成”——这是成功状态（fulfilled）。但如果你点的菜恰好今天卖完了，老板会过来道歉，小票变成“已取消”——这是失败状态（rejected）。一张小票，三种命运，而且一旦从“备餐中”变成“已完成”或“已取消”，就再也不会变回去。菜都端上桌了，不可能重新变回“备餐中”。

Promise对象就是这张小票。它用 new Promise(executor) 创建，executor 是“老板的记事本”，里面写着你点的菜要怎么做。executor 接收两个函数：resolve（菜做好了）和 reject（菜做砸了）。一旦调用 resolve，Promise 就从 pending 变为 fulfilled；调用 reject，就从 pending 变为 rejected。这两条路都是单行道，不可逆转。这个“状态不可逆”特性至关重要——它保证了同一个操作的结果是确定性的，不会出现“先成功又失败”的诡异局面。

1. 创建Promise：new Promise(executor) 创建一张小票，executor 立即执行，好比老板收到订单马上开工。

$$\text{Promise} = \text{new Promise}(\text{executor})，\text{executor 立即执行}$$

2. pending 状态：executor 还没调用 resolve 或 reject 时，小票停留在“备餐中”。

$$\text{pending} = \text{备餐中}，\text{等待} \text{resolve} / \text{reject} \text{被调用}$$

3. resolve 触发 fulfilled：调用 resolve(value) 后，小票变成“已完成”，value 是端上桌的菜。

$$\text{fulfilled} = \text{resolve}(\text{value})，\text{value 传递给后续消费者}$$

4. reject 触发 rejected：调用 reject(reason) 后，小票变成“已取消”，reason 是取消原因。

$$\text{rejected} = \text{reject}(\text{reason})，\text{reason 是失败原因}$$

5. 状态不可逆：一旦 fulfilled 或 rejected，状态永久锁定，再调用 resolve/reject 无效。

$$\text{状态} \in \{\text{pending}, \text{fulfilled}, \text{rejected}\}，\text{转换仅一次，不可逆}$$

这张小票最妙的地方在于：你不需要一直盯着后厨看。拿到小票后，你可以继续做自己的事。当状态变化时，Promise 会自动通知“关注这张小票的人”。怎么关注？就是下一节要讲的 .then() 方法——相当于在小票上写了“做好后打电话通知我”。小票是媒介，真正的价值在于它让“等待”变得可管理、可组合。

var myOrder = new Promise(function(resolve, reject) {  // 模拟做菜过程：2秒后决定命运  setTimeout(function() {    var dish = '拉面';    var success = true;    if (success) {      resolve(dish);  // 菜做好了，小票变成 fulfilled    } else {      reject('今天卖完了');  // 菜做砸了，小票变成 rejected    }  }, 2000);}); console.log(myOrder);  // 立即输出：Promise { <pending> }// 2秒后，小票状态变成 fulfilled 或 rejected

链式调用：从嵌套地狱到流水线

在Promise出现之前，JavaScript的异步代码长什么样？想象一下，你要点一碗拉面，需要经过“下单→付款→等餐→取餐”四个步骤，每一步都是异步的。用回调函数写，就像俄罗斯套娃一样一层套一层：

这就是著名的回调地狱。代码不断向右缩进，逻辑顺序是“先外后内”，读起来像解谜。更可怕的是，每一层的错误处理都要单独写，漏一个就可能“静默失败”——菜做砸了没人知道。

Promise的链式调用彻底改变了这个局面。它的核心机制是：.then() 方法会返回一个新的Promise，这个新Promise的状态取决于回调函数的返回值。就像流水线一样，每道工序完成后的“半成品”自动传给下一道工序。每一层是扁平的一个点，而不是嵌套的一层壳：

1. then方法：.then(onFulfilled) 注册一个“菜好了通知我”的监听器，它接收小票成功后的值。

$$\text{promise}.\text{then}(\text{onFulfilled})：\text{注册成功的回调}$$

2. 返回值包装：.then() 的回调返回的任何值，都会被包成新的Promise，实现接力。

$$\text{回调返回值} \Rightarrow \text{新Promise}，\text{值自动传递到下一环}$$

3. 链式扁平化：每步一个 .then() 平铺，替代嵌套回调的层级结构。

$$\text{嵌套} O(n) \text{层} \Rightarrow \text{链式} n \text{个} \text{.then()} \text{平铺}$$

4. 返回值透传：如果回调返回的不是Promise而是一个普通值，它会被包装成已完成的Promise，继续传递。

$$\text{return 普通值} \Rightarrow \text{Promise.resolve(值)} \Rightarrow \text{继续流转}$$

流水线的比喻在这里非常贴切：每一道工序都只关心自己的活——切菜的不管炒菜，炒菜的不管装盘。但每一道工序结束后的“半成品”都自动送到下一道工序。这种关注点分离不仅让代码清晰，还让错误处理变得异常简单——整条流水线只要在末端装一个“Catch机”，任何一道工序出问题，都能被它接住。

// 回调地狱：像套娃一样一层层嵌套，代码横向生长placeOrder(function(order) {  pay(order, function(receipt) {    waitForDish(receipt, function(dish) {      pickUp(dish, function(result) {        console.log('终于吃上了', result);      });    });  });});

// 链式调用：像流水线一样扁平，每步都返回新PromiseplaceOrder()  .then(function(order) {    return pay(order);        // 工序2：付款，返回新Promise  })  .then(function(receipt) {    return waitForDish(receipt);  // 工序3：等餐  })  .then(function(dish) {    return pickUp(dish);      // 工序4：取餐  })  .then(function(result) {    console.log('终于吃上了', result);  });

错误处理：厨房里的消防系统

深夜食堂的厨房里，有一套完整的消防系统。每个灶台旁边有灭火器，天花板上烟雾报警器，后门有安全通道。一旦哪个灶台起火，灭火器会第一时间扑救；如果火势变大，报警器会响彻全楼。厨房不可能因为怕起火就不做饭——关键是要有一套“兜底”机制。Promise的错误处理设计，就是这套消防系统。

在同步代码中，你可以用 try/catch 接住任何异常。但在Promise出现之前，异步代码的错误处理是噩梦——每个回调函数里都要写 if (error) 的判断，漏一个就“静默失败”。Promise用 .catch() 方法统一接管错误。更妙的是，异常穿透机制：Promise链上任何一环出错（throw或reject），错误会自动跳过中间的 .then()，直达最近的 .catch()。就像烟雾报警器一样，不管火源在哪一层，警报都会传到消防中心。

1. catch方法：.catch(onRejected) 是 .then(null, onRejected) 的语法糖，专门接住失败。

$$\text{promise}.\text{catch}(\text{onRejected}) \equiv \text{promise}.\text{then}(\text{null}, \text{onRejected})$$

2. 异常穿透：链上任意一环抛出异常或reject，后续的 .then() 全部跳过，直达 .catch()。

$$\text{error} \Rightarrow \text{跳过中间then} \Rightarrow \text{直达最近catch}$$

3. throw与reject等价：在 .then() 回调中 throw new Error()，相当于返回一个rejected的Promise。

$$\text{throw err} \Leftrightarrow \text{return Promise.reject(err)}$$

4. finally清理：无论成功还是失败，.finally() 里的代码一定会执行，适合做清理工作。

$$\text{finally}：\text{无论 fulfilled 或 rejected 都执行，不改变结果}$$

消防系统的设计哲学是：不要假设不会着火，而要确保火了能灭。同样的，优秀的异步代码不是“不会出错”，而是“出错后能被优雅地接住”。在实际项目中，.catch() 通常用来展示错误提示、记录日志、恢复默认状态；.finally() 用来关闭loading动画、释放资源。这套体系让异常不再“静默”——每一个错误都变成可见的、可处理的事件。

// 错误处理的完整体系：try/catch + catch + finallyplaceOrder()          // 第一步：下单  .then(pay)          // 第二步：付款（可能失败）  .then(waitForDish)  // 第三步：等餐  .then(pickUp)       // 第四步：取餐  .catch(function(error) {    console.log('订单流程出错了：', error);  // 任何一步出错都到这  })  .finally(function() {    console.log('无论成败，收拾桌面');  // 清理资源、关loading  });

async/await原理：让小票看起来像现场吃

用Promise链式调用，代码已经从“套娃”变成了“流水线”，但终究还是有点“弯弯绕”。能不能让异步代码长得像同步代码一样直白？比如这样：

这就是 async/await——JavaScript异步编程的终极形态。它的本质是语法糖：async 关键字声明一个函数“内部会有异步操作”，await 关键字表示“在这里暂停，等Promise出结果再继续”。看起来像同步，实际上底层依然是Promise和回调。你拿到的小票还在，只是你不用一直盯着它看了——你坐下来，服务员会在菜好的时候端上来，你只需要“假装”在等就好。

async/await 的底层实现离不开生成器（Generator）。生成器函数用 function* 声明，支持在任意位置“暂停”和“恢复”。async/await 本质上就是把生成器包装起来：await 后面的表达式被编译成“暂停点”，Promise完成后自动恢复执行。这个机制，就像传菜员在你面前放了一个“暂停”按钮——菜没到，函数就停在那里；菜一到，按钮自动弹起，函数继续往下走。

1. async函数：用 async 声明的函数，返回值自动被包装成Promise。

$$\text{async fn}(x) \Rightarrow \text{返回 Promise}，\text{内部 return 值} \Rightarrow \text{fulfilled}$$

2. await操作符：await 可以理解为“暂停并等待”，它后面跟一个表达式，通常是一个Promise。

$$\text{await promise} \Rightarrow \text{暂停当前async函数}，\text{等待promise结算}$$

3. 错误捕获：await 等到的如果是rejected Promise，会直接抛出异常，可用 try/catch 接住。

$$\text{await 到 rejected} \Rightarrow \text{throw reason}，\text{try/catch 捕获}$$

4. 生成器原理：function* 生成器通过 yield 暂停，通过 next() 恢复，async/await 是其自动化的封装。

$$\text{generator} = \text{yield 暂停} + \text{next() 恢复}，\text{async/await 自动驱动}$$

深夜食堂的比喻在这里到了高潮：以前你要拿小票、听广播、自己注意叫号；现在你直接坐下来，服务员帮你盯着所有进度，菜到了自然端到你面前。你的代码像同步一样“顺滑”，但底层依然是异步的——你没阻塞任何其他客人。这就是 async/await 的魅力：给程序员同步的心智模型，给系统异步的高效利用。

// 同步风格的异步代码：看起来像在排队，实际上是异步async function eatNoodles() {  var order = await placeOrder();        // 同步式：下单  var receipt = await pay(order);        // 同步式：付款  var dish = await waitForDish(receipt); // 同步式：等餐  var result = await pickUp(dish);       // 同步式：取餐  return result;}

// async/await 的底层简化原理：生成器 + 自动执行器function* gen() {  var order = yield placeOrder();        // 暂停点1：等下单结果  var receipt = yield pay(order);        // 暂停点2：等付款结果  var dish = yield waitForDish(receipt); // 暂停点3：等餐  return dish;} function autoRun(genFn) {  var it = genFn();  // 生成器对象  function next(val) {    var r = it.next(val);  // 恢复执行，传入上一个结果    if (r.done) return r.value;  // 生成器走完了    // r.value 是一个Promise，等它好了再恢复执行    r.value.then(next);  }  next();} autoRun(gen);  // 像 async/await 一样自动跑完整个流程

并发控制：一张桌子的团队协作

深夜食堂来了六位客人，他们是一起的，想在同一桌吃饭。但每个人点的菜耗时不同——拉面三分钟，煎饺两分钟，白粥三十秒。如果按顺序一个一个做，总共要五分钟；如果三口锅同时开火，三分钟就能全部上齐。这就是并发（Concurrency）的价值：不是同时做一件事，而是多个任务交叉推进，让整体耗时取决于最长的那道菜，而非所有菜的总和。

Promise.all 就是“同时开三锅”的利器。它接收一个Promise数组，等所有Promise都变为fulfilled后，返回一个包含所有结果的新Promise。任何一个失败，整个 Promise.all 立即失败。对应到食堂：六位客人的菜全部上齐才算一起开饭，有一道菜做砸了，整桌都吃不成。这种“全有或全无”的语义，非常适合“先并行请求多个接口，再统一渲染页面”的场景。

1. Promise.all：并发执行多个Promise，全部成功才返回结果数组，一个失败则整体失败。

$$\text{Promise.all}([p_1, p_2, \ldots, p_n]) \Rightarrow [r_1, r_2, \ldots, r_n]，\text{全部成功才整体成功}$$

2. Promise.race：并发执行多个Promise，只看第一个落定（成功或失败）的结果，其余忽略。

$$\text{Promise.race}([p_1, p_2, \ldots, p_n]) \Rightarrow \text{第一个settled的结果}$$

3. Promise.allSettled：并发执行多个Promise，等全部落定后，返回每个Promise的结果对象（成功或失败都记录）。

$$\text{allSettled} \Rightarrow [\{\text{status}, \text{value/reason}\}]，\text{不因某个失败而整体失败}$$

4. 性能优化：并行请求比串行请求总耗时更短——总耗时 = 最慢任务耗时，而非任务耗时之和。

$$\text{串行} = t_1 + t_2 + \cdots + t_n，\text{并行} = \max(t_1, t_2, \ldots, t_n)$$

Promise.all 和 Promise.race 就像厨房里的两种协作模式：前者是“家庭聚餐，人齐了才动筷”；后者是“比赛吃面，第一碗上来了先吃”。而 allSettled 更像“外卖订单记录”——不管每个订单成功还是失败，都要有一个最终记录归档，方便复盘。在实际开发中，它们分别对应“多接口数据聚合”“超时控制”“部分失败容错”三大经典场景。理解并发控制，你的异步代码才能从“能跑”进化到“快跑”。

// 并发请求：三个接口同时发起，全部完成后再统一处理async function loadDashboard() {  var [userInfo, orderList, statistics] = await Promise.all([    fetch('/api/user/info'),       // 请求1：用户信息    fetch('/api/user/orders'),     // 请求2：订单列表    fetch('/api/user/statistics')  // 请求3：数据统计  ]);  return { userInfo, orderList, statistics };}

AI 应用场景

Python 演示

"""Promise 核心机制的 Python 教学模拟：用生成器和回调模拟 JavaScript Promise 的状态流转"""import timeimport threadingfrom collections import deque  class SimplePromise:    """模拟 JavaScript Promise：三种状态 + then 链式调用"""     def __init__(self, executor):        self._state = "pending"  # pending / fulfilled / rejected        self._value = None        self._handlers = deque()        try:            executor(self._resolve, self._reject)        except Exception as e:            self._reject(e)     def _resolve(self, value):        self._state = "fulfilled"        self._value = value        self._flush()     def _reject(self, reason):        self._state = "rejected"        self._value = reason        self._flush()     def _flush(self):        while self._handlers:            cb = self._handlers.popleft()            self._dispatch(cb)     def _dispatch(self, cb):        try:            result = cb(self._value)        except Exception as e:            self._reject(e)     def then(self, on_fulfilled):        next_promise = SimplePromise(lambda res, rej: None)        if self._state == "pending":            self._handlers.append(on_fulfilled)        else:            self._dispatch(on_fulfilled)        return next_promise     def catch(self, on_rejected):        return self.then(on_rejected)  def async_task(name, delay):    """模拟一个异步任务：延迟后返回结果"""    def executor(resolve, reject):        def runner():            time.sleep(delay)            resolve(f"{name} 完成")        threading.Thread(target=runner).start()    return SimplePromise(executor)  if __name__ == "__main__":    print("=== Promise 状态流转模拟 ===")    p = async_task("拉面", 0.5)     def on_done(value):        print("收到:", value)        return "下一道工序"     p.then(on_done)    print("主线程不阻塞，先做其他事...")    time.sleep(1)

1. self._state = "pending"Promise 初始状态，对应“菜还没做好”的小票
2. executor(self._resolve, self._reject)构造函数立即执行“老板的记事本”，传入两个决定命运的函数
3. self._state = "fulfilled"` / `"rejected"状态一旦切换就不可逆，验证了“小票命运单行道”的特性
4. self._handlers.append(on_fulfilled)pending 状态下的回调先存入队列，等状态定了再执行
5. threading.Thread(target=runner).start()用子线程模拟异步操作，主线程不阻塞
6. p.then(on_done)注册“菜好了通知我”的监听器，返回的 next_promise 支持继续链式调用

常见误区

面试题