一般从书籍或者博客阅读了关于事件循环的部分后，对js的异步机制便有了大致了解，但也容易产生一些疑问。陆续看了足够多的复读机们的解释后，这里补充一些注意点。
包含在<script>内的整段代码是宏任务队列的开头
在尚未意识到这一点时，容易产生微任务先于本轮宏任务执行的错觉；node没有script标签，自然指的是执行的整段代码。微任务优先于当前调用栈产生的宏任务被执行。比较特殊的是，代表宏任务的这整段代码包含了其它宏任务，执行后（产生宏任务队列和微任务队列）便从事件循环中被移除了。一轮EventLoop并不意味着script中的代码都被执行完了，遇到另外的宏任务比如setTimeout时，指定时间后会被推入任务队列，不管其中有没有另外的宏任务和微任务。
<script>
setTimeout(function setTimeout1 (){ ... })}, 0)
setTimeout(function setTimeout2 (){ ... }, 0)
Promise.resolve().then(function promise1 () { ... })
</script>
| 轮数 | macrotask | microtask |
|---|---|---|
| 第一轮 开始 | script | |
| 第一轮 执行 | setTimeout1 ,setTimeout2 | promise1 |
| 第一轮 结束（第二轮开始） | setTimeout1 ,setTimeout2 |
一轮事件循环中先执行macrotask，再执行microtask。macrotask是取队列中的一项执行，microtask是清空队列，并且执行microtask中的任务时可能会源源不断产生新的微任务，都算作本轮应该被执行的微任务（产生的宏任务自然算作下一轮）。
<script>
setTimeout(function setTimeout1() { //1
console.log("set1");
}, 0)
setTimeout(function setTimeout2() { //2
console.log("set2");
}, 0)
Promise.resolve().then(function promise1() { //3
console.log("pro1");
Promise.resolve().then(function promise1() { //3.a
console.log("pro2")
}).then(function() {
console.log("pro4")
})
setTimeout(function() { //3.1
console.log("set3")
Promise.resolve().then(function promise1() {
console.log("pro5")
}).then(function() {
console.log("pro6")
})
}, 0)
return new Promise(function(resolve, reject) {
setTimeout(function() {
resolve("yes")
}, 0) //3.2
console.log("block return")
setTimeout(function setTimeout2() { //3.3
console.log("set4");
}, 0)
})
}).then(function(val) {
console.log(val)
console.log("pro3")
})
</script>
比如微任务代码块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）之前必须确保执行栈为空。有些时候，宏任务比如<script>代码，执行过程中产生了微任务，但在梳理流程时注意；当你认为微任务应该执行时，<script>究竟出栈没有。在这里，有个具体例子的探讨。
为什么如此划分
我们机械接受了事件循环的种种定义，但最好多问问这样设计的理由。一般情况下，我们使用macrotask，但需要以同步方式来处理异步时，离不开微任务的特性——有新的微任务添加进来会在本轮执行，比如需要反复修改计算dom时。这样，在UI每次渲染前，微任务都异步更新了数据。特别是大量任务累积情况下，如果想要快速更改数据则需要使用microtask。
UI更新不是必要的
浏览器会在一轮宏任务和微任务执行完成后重新渲染，这意味着一轮eventloop中如果出现了多次修改dom的操作，最后一次才会反映在渲染上，但这也不是必然发生的。在一帧时间内进行了多轮eventloop并修改dom，这些修改会累积起来进行一次绘制。如果要在每轮循环中进行渲染，应该使用requestAnimationFrame。
参考
