对Event Loop的非必要补充

一般从书籍或者博客阅读了关于事件循环的部分后，对js的异步机制便有了大致了解，但也容易产生一些疑问。陆续看了足够多的复读机们的解释后，这里补充一些注意点。

包含在

轮数	macrotask	microtask
第一轮 开始	script
第一轮 执行	setTimeout1 ,setTimeout2	promise1
第一轮 结束（第二轮开始）	setTimeout1 ,setTimeout2

一轮事件循环中先执行macrotask，再执行microtask。macrotask是取队列中的一项执行，microtask是清空队列，并且执行microtask中的任务时可能会源源不断产生新的微任务，都算作本轮应该被执行的微任务（产生的宏任务自然算作下一轮）。

比如微任务代码块3在执行过程中产生了微任务3.a，3.a会在本轮执行；产生的宏任务3.1、3.2、3.3会在下一轮。可以试着将then的返回值改为非阻塞，或者阻塞时间大于0再次分析。

js是单线程语言，但浏览器浏览器可不只有一个线程

最明显的例子是定时器：单线程是如何能做到等待指定时间后将函数放入队列，这期间还在往下执行代码？尽管js引擎是单线程从头到尾执行，但宿主环境提供了诸多辅助线程。定时器、浏览器事件、http请求、UI渲染等都是另有线程负责的。js所维护的任务队列实质上是宿主环境返回的一个个回调函数。

setTimeout作为发起（注册）函数，将回调函数放入宏任务队列

setTimeout设置了定时器，到时间后，它才会将回调函数放入宏任务队列待主线程读取。所以setTimeout函数虽然标志了异步，它确实被顺序执行了。能够向队列加入事件的"代码"基本都类似于此：被主线程执行，然后返回结果；异步调用完成了，但是异步过程尚未结束。拿ajax请求来说，js引擎执行到该段代码为http请求后，便通知对应的线程接管（异步调用完成）。js引擎继续向下执行，而在另一线程里，ajax取得结果后便将回调函数放入任务队列。主线程空余后，在任务队列中依次取出回调函数执行，包括ajax对应的回调。

node的事件循环与浏览器的实现有所不同

先空着吧。或者直接看参考。

前端谈论"异步"时，大部分情况其实在说"非阻塞"

异步的关注点是“Don't call me ,I call you”，我们确实明白回调函数是被对应线程通知后，放入队列中的，但更关心的是，耗时的或者不确定的操作究竟有没有阻塞后续的代码。

promises属于微任务队列？

HTML标准里指明了task的来源，但没有明确micro-task的来源，大部分浏览器借由micro-task实现then方法，有些则通过macro-task，不过一般认为promises是属于microtask。
关于promises，要注意：
1 使用 new Promise((resolve)=>{ ... resolve(something) ...}) 时，传入构造函数的参数（也是函数），会被填入内置的resolve和reject后同步执行，即，resolve之外的非Promise代码会被立即执行，如果something非thenable，将之作为该promise的决议，如果是thenable，会作为microtask被异步地展开后得出该promise的值。也就是说在promise中resolve(thenable)和thenable.then()才会产生微任务。
2 使用API (静态函数) Promise.resolve(thenable)和new Promise((thenable)=>{ resolve(thenable) }) 产生的结果不一样。

await被翻译成了什么

await右侧表达式会先被先执行，但会阻塞async内后续代码，主线程跳出async执行外面的代码，之后再回到async内部，await取得表达式值后继续向下执行。“跳出”这个动作说明await之后的代码被视为task，自然是micro-task，可以将之转化为promise代码来分析。略去严谨的分析，直觉上将后续内容推入微队列即可，

await p //p为右侧表达式结果
...
//async后其余代码
 等同于   
new Promise((resolve)=>{resolve(p)}).then(()=>{...})

这样粗略一看，后续代码处于和async一轮的微队列中，但这在p不是thenable和promise的前提下才成立。
根据前面所说

new Promise((resolve)=>{resolve(thenable)})
//会被转换成
new Promise(resolve => {
  Promise.resolve().then(() => {
    thenable.then(resolve)
  })
})

因此

await thenable
...
//等同于
new Promise(resolve => {
    Promise.resolve().then(() => {
      thenable.then(resolve)
    })
  }).then(() => {
    ...
  })
}

这样一看将（...）“推入”微队列似乎并没有多么直觉–––时序上晚了许多。所幸地是，await更新了规范：

await thenable
...
//更新规范后
Promise.resolve(thenable).then(() => { ... })
//即
thenable.then(() => { ... })

微任务？宏任务？

《You Don't Know JS》中提到Event Loop时只有job queue这个概念，但一搜索博客时，铺天盖地都在谈论macrotask、microtask。查阅一番后，在https://html.spec.whatwg.org/multipage/webappapis.html#event-loops
可以找到比较准确的说法，根据链接，也确定前面的解释---宿主环境配合实现了Event loop。我们在谈论 task queue时，指的就是macrotask，会特别指明microtask时指的是job queue，比如promise，process.nextTick，Object.observe，MutationObserver。事件循环里处理的也被统一称为了task，job queues其实也和microtask没太多关系，因为一个是ECMAScript的规范，一个是HTML的标准。
规范详细指明了事件循环的各个阶段，需要关注的一点是开始微任务（即规范里的microtask checkpoint）之前必须确保执行栈为空。有些时候，宏任务比如