js在浏览器和node中的解析机制-Event Loop

        先看一道常见的事件循环代码题：

console.log('1');

setTimeout(function() {
    console.log('2');
    new Promise(function(resolve) {
        console.log('4');
        resolve();
    }).then(function() {
        console.log('5')
    })
})
new Promise(function(resolve) {
    console.log('7');
    resolve();
}).then(function() {
    console.log('8')
})

setTimeout(function() {
    console.log('9');
    new Promise(function(resolve) {
        console.log('11');
        resolve();
    }).then(function() {
        console.log('12')
    })
})

       尝试一下在浏览器执行的顺序是：1 7 8 2 4 5 9 11 12

       我们都知道，js的解析是单线程的，任务都需要一个接一个的执行。js中的任务又分为同步任务和异步任务。进入主线程时，同步任务按代码顺序执行，遇到异步任务会先注册，把回调函数加入到事件队列event queue中等待。主线程同步任务执行完后，按顺序再去读取队列中的异步任务来执行。

       而异步任务又分为两种：

• 宏任务：如setTimeout延时器
• 微任务：如promise的回调函数

       本轮循环一定是早于次轮循环的，微任务是追加在本轮循环的，宏任务是追加在次轮循环的。

       在同步任务执行完毕后，会先读取微任务执行完后，再执行宏任务。如果在宏任务执行时遇到微任务，这个宏任务执行完后，依旧会先执行微任务，再执行其他的宏任务。也就是微任务总是先于宏任务执行。

       这里也就是为什么，在第一个setTimeout执行时，遇到了新的promise回调微任务，会先执行这个微任务，再去执行本次宏任务队列里剩下的那个setTimeout回调。

       这里要注意的是，new Promise()这个构造函数里的任务，也是会立即执行的同步任务，要跟then回调区分开。

其实上面的代码因为想在浏览器执行，我去掉了一些process.nextTick的部分，原代码如下：

console.log('1');

setTimeout(function() {
    console.log('2');
    process.nextTick(function() {
        console.log('3');
    })
    new Promise(function(resolve) {
        console.log('4');
        resolve();
    }).then(function() {
        console.log('5')
    })
})
process.nextTick(function() {
    console.log('6');
})
new Promise(function(resolve) {
    console.log('7');
    resolve();
}).then(function() {
    console.log('8')
})

setTimeout(function() {
    console.log('9');
    process.nextTick(function() {
        console.log('10');
    })
    new Promise(function(resolve) {
        console.log('11');
        resolve();
    }).then(function() {
        console.log('12')
    })
})

       尝试一下在node执行的顺序是：1 7 6 8 2 4 9 11 3 10 5 12，惊奇的发现和浏览器里的执行顺序并不相同。

       主要在于宏任务执行的阶段，在node环境下，在第一个setTimeout执行时，遇到了promise回调的微任务并不会让步，而是暂时添加到微任务队列，等到这一次的第二个setTimeout宏任务也完成，再去执行process.nextTick以及其他的微任务。

       简单的梳理完，上面的打印顺序也就迎刃而解啦。然后再看一个进阶的：

async function async1(){
    console.log('async1 start')
    await async2()
    console.log('async1 end')
  }
async function async2(){
    console.log('async2')
}
console.log('script start')
setImmediate(() => console.log('setImmediate'));
setTimeout(function(){
    console.log('setTimeout0') 
},0)  
setTimeout(function(){
    console.log('setTimeout3') 
},3)  
process.nextTick(() => console.log('nextTick'));
async1();
new Promise(function(resolve){
    console.log('promise1')
    resolve();
    console.log('promise2')
}).then(function(){
    console.log('promise3')
})
console.log('script end')

node执行一下，顺序是：

再刚才的基础上，我们再补充一下：

1. node中增加了process.nextTick()  ，虽然也是异步执行，但是不会给其他事件执行的机会。也就是说：它总会在当前阶段执行结束的时候优先执行。这里要注意的是，它的优先级是高于微任务的。
2. setTimeout 在 timers 阶段执行，而 setImmediate 在 check 阶段执行。所以，setTimeout 会早于 setImmediate 完成。（具体要去了解一下node里面事件循环的操作顺序...）
3. async/await函数，我们都知道它返回的是一个promise对象，在执行时，遇到await会阻塞代码，先触发异步操作，执行完毕后再接着执行函数体后面的语句。

       这样但看async/await还是会有疑惑，再执行完await async2()后，为什么走到了“promise1”而不是“async1 end”？

       个人理解，async2函数返回的仍然是一个promise对象：

async function async2(){
    console.log('async2')
}

// 相当于：
async function async2(){
    new Promise((resolve,reject) => {
        console.log('async2')
        resolve()
    })
}

       在返回promise之后，回到async1函数里，在它后面的语句相当于放在这个promise的回调函数里，因此注册了微任务，不会立即执行，等到本轮同步任务执行完成后才会再执行。