宏任务和微任务都讨论了好几年了，前端面试也考了这么多回了，各位客爷也一定对这方面知识有所了解，如果还是一知半解的话，请先自行百度或者翻看一下在下的这篇博文：初识宏任务与微任务
今天这篇文章主要是再往深了刨一刨为啥有的宏任务微任务之分，具体效果体现在了哪儿。并记录了自己的验证过程，如有错误，客爷们蛋喷无妨及时指正~
先说说背景吧~
话说这js打出生时就是个供浏览器内核用的小脚本，没有什么二进制操作，也没有进程线程的概念。它唯一的优点就是快，事件驱动，异步回调，所以我们刚学习js时经常会遇到一种比较特殊的写法叫”回调函数“（这种回调写法并不是js中才有的哟）。
就是因为js中常常存在非即时性操作。比如ajax请求，定时器，页面渲染完成(onload)，鼠标点击事件（onclick）等。
———————————————— 时间线2015年 —————————————————
这个时候伟大的es6出现了，提出了一个可以让我们在回调地狱中解放的api叫做 promise。
这也就导致了之前在学习js的时候我们理解个同步代码和异步代码就够了，这货出来还要分个宏任务和微任务。
我们这里简单过一下微任务的产生原因吧，以下是我从网上抄的概念⬇️
注意这句话：“在时效性和效率之间做一个有效的权衡”
这句话应该怎么理解呢？
首先我们来说说时效性，微任务归根结底还是异步执行的代码，所以它一定还是比同步代码要慢！
接着我们来聊一下他的效率，微任务的代码纯粹就是为了异步操作，并没有任何延时需要，所以它又是异步代码中最快的！
而它的快体现在了哪里呢？体现在了它会在Dom重新渲染+宏任务执行之前，所以我们可以摸清一个套路，事件循环的顺序是：
微任务 ——> Dom渲染 ——> 宏任务
—— 高级装逼工程师 Yubble
接下来我们就要用代码来证明这个理论了
no code，no bibi，看下面这段代码：
我们如果运行这段代码就可以明显的看到，虽然 main.appendChild 在同步代码中执行，但是时间顺序是这样的：
1、控制台中先打印出的‘微任务已经执行’
2、id 等于 main 的这个 div 渲染出了 100000 行的 li（此处耗时明显）
3、最后控制台打印‘宏任务执行’
可能有别的客爷就问了，问什么要拿控制台中的console.log和页面上的文字比，不直接把异步回调执行时的文字写到浏览器上的div渲染出来，不就能看到执行顺序了吗？答案是，这样做的话浏览器显示肯定异步的文字就全在li标签之后了，因为都不管同步异步都变成Dom渲染了。
最后通过这个Demo，我们也得出了一个结论：不要在.then()中写耗时的循环，会影响后续Dom渲染以及宏任务的释放。可自行验证：
以上就是我全部的调研过程与结果，五一的假过完了，给自己安排的作业还没写完，昨天看了一篇文章，说我们这代年轻人都得了‘急躁症’，不管做什么和工作或成长无关的事都觉得是在浪费时间，总觉得自己时间不够用。
唉，可能我们老一辈的奋斗者也经历过这段过程吧，不然他们怎么能成为中流砥柱呢。不过激进归激进，不要控制不住而伤害到身边的人就好。最后祝大家身体健康，准备投身工作吧。
