1. 题目和答案
故事还是要从下面这道面试题说起:请问下面这段代码的输出是什么?
1 | console.log("script start"); |
上述,在Chrome 66
和node v10
中,正确输出是:
1 | script start |
注意:在新版本的浏览器中,
await
输出顺序被“提前”了,请看官耐心慢慢看。
2. 流程解释
边看输出结果,边做解释吧:
- 正常输出
script start
- 执行
async1
函数,此函数中又调用了async2
函数,输出async2 end
。回到async1
函数,遇到了await
,让出线程。 - 遇到
setTimeout
,扔到下一轮宏任务队列 - 遇到
Promise
对象,立即执行其函数,输出Promise
。其后的resolve
,被扔到了微任务队列 - 正常输出
script end
- 此时,此次
Event Loop
宏任务都执行完了。来看下第二步被扔进来的微任务,因为async2
函数是async
关键词修饰,因此,将await async2
后的代码扔到微任务队列中 - 执行第 4 步被扔到微任务队列的任务,输出
promise1
和promise2
- 执行第 6 步被扔到微任务队列的任务,输出
async1 end
- 第一轮 EventLoop 完成,执行第二轮 EventLoop。执行
setTimeout
中的回调函数,输出setTimeout
。
3. 再谈 async 和 await
细心的朋友肯定会发现前面第 6 步,如果async2
函数是没有async
关键词修饰的一个普通函数呢?
1 | // 新的async2函数 |
输出结果如下所示:
1 | script start |
不同的结果就出现在前面所说的第 6 步:如果 await 函数后面的函数是普通函数,那么其后的微任务就正常执行;否则,会将其再放入微任务队列。
4. 其实是 V8 引擎的 BUG
看到前面,正常人都会觉得真奇怪!(但是按照上面的诀窍倒也是可以理解)
然而 V8 团队确定了这是个 bug(很多强行解释要被打脸了),具体的 PR请看这里。好在,这个问题已经在最新的 Chrome 浏览器中被修复了。
简单点说,前面两段不同代码的运行结果都是:
1 | script start |
await
就是让出线程,其后的代码放入微任务队列(不会再多一次放入的过程),就这么简单了。