为什么要EventLoop？
JS 作为浏览器脚本语言，为了避免复杂的同步问题（例如用户操作事件以及操作DOM），这就决定了被设计成单线程语言，而且也将会一直保持是单线程的。而在单线程中若是遇到了耗时的操作（IO，定时器，网络请求）将会一直等待，CPU利用率将会大打折扣，时间大量浪费。所以需要设计一种方案让一些耗时的操作放在一边等待，让后面的函数先执行，于是有了EventLoop的设计。
将任务分为两种：
同步任务
异步任务
定时器都是异步操作
事件绑定都是异步操作
AJAX中一般采取的异步操作（虽然也可以同步）
回调函数（不严谨的异步）
阮一峰老师《JavaScript 运行机制详解：再谈Event Loop》
（1）所有同步任务都在主线程上执行，形成一个执行栈（execution context stack）。
（2）主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件。
（3）一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行。
（4）主线程不断重复上面的第三步。
任务都会按顺序进入调用栈（call stack），即图1-1的stack，然后按栈的顺序依次执行。若全是同步任务，就会正常地顺序执行。当遇到异步任务时（其实就是执行到了一个耗时的任务，它发起后，需要它的回调函数等待拿到结果之后才继续进行）将会放到WebAPIs中（图1-1），等待这个耗时操作返回结果，也有网友把这个 WebAPIs 称之为 Event Table。如果异步任务在WebAPIs中等待有了结果（比如setTimeout的时间截止了，xhr得到响应结果了，用户click事件发生了），就会将这个结果作为一个事件置于任务队列中。 【或者称之为：注册回调函数】
那么任务队列又是什么？个人认为就是图中的callback queue，或称之为 Event Queue 。就是存放了各种耗时操作最后响应结果的各个事件（说白了，就是已经拿到结果的，就会从WebAPIs放到任务队列里来）
搞懂上面两段话后，就可以谈EventLoop的作用了：
在调用栈和任务队列之间进行“轮询”
但轮询的规则是：只有每当调用栈为空，才能去“询问”任务队列中是否有事件需要处理
若任务队列存在事件，则会将该事件相应的回调函数（异步操作）结束等待，置于调用栈中开始执行
如果调用栈一直不为空，那就一直不会“询问”任务队列
以上过程是不断循环的，js引擎中，存在一个叫monitoring process的进程，这个进程会不断的检查主线程的执行情况，一旦为空，就会去任务队列检查有哪些待执行的函数。这里的整个过程可以参考 一个工具 loupe 对整个调用过程进行查看。
图 1-2 loupe, 也是从其他地方发现的这个东西，很直观
针对call stack调用栈多说一句：通俗地讲，将调用栈比喻为程序员，各个任务比喻为需求，任务队列比喻为总监。当总监提需求时，程序员就要交接需求过来，然后完成它。如果没有需求，就一直等待总监给需求。给了就做，不给就等。
搞懂同步任务与异步任务的具体执行流程后，再谈谈为什么要设计宏任务和微任务。
为什么有宏任务、微任务？页面渲染事件，各种IO的完成事件等随时被添加到任务队列中，一直会保持先进先出的原则执行，我们不能准确地控制这些事件被添加到任务队列中的位置。但是这个时候突然有高优先级的任务需要尽快执行，那么若只有一种类型的任务就不合适了，所以引入了微任务队列。
至此，任务队列已被分为：
宏任务队列，即上文说的任务队列，callback queue，用于存放宏任务
微任务队列，再开辟一个队列，用于存放微任务
图 2-1 微任务Microtask Queue的加入
首先列举一下哪些是宏任务、哪些是微任务
宏任务：
script(主代码)
setTimeout()
setInterval()
postMessage
I/O
UI交互事件
setImmediate(Node.js)
requestAnimationFrame(浏览器)
微任务：
new Promise().then(回调)
MutationObserver(html5 新特性)