Promise为什么要引入微任务
Promise中的执行函数是同步的，但是其中存在着异步操作，在异步操作结束后调用resolve方法，或者中途遇到错误调用reject方法，这两者都是作为微任务添加到EventLoop中。而为什么会有微任务呢
处理回调问题的结局方式
- 使用同步回调，直到所有的异步任务进行完在进行后面的任务
- 使用异步回调，将回调函数放在所有当前宏任务队列的队尾
- 使用异步回调，将回调函数放在当前宏任务的最后面
对比
第一种方式不可取，因为同步的方式会影响整个程序的执行效果，如果一个任务的执行时间很长，会影响接下来的任务，而这部分等待时间是可以用来做别的事情，导致CPU利用率很低。除此以外，还会无法实现延迟绑定的效果 第二种方式执行回调函数的时机是在当前所有的宏任务执行完毕之后，如果现在有很多宏任务要执行，也会造成阻塞，这个回调函数就会迟迟不能执行，造成页面卡顿 基于以上的原因，Promise采用了第三种方式，也就是引入了微任务，将回调函数放在了当前的宏任务的末尾。
解决痛点
- 采用异步回调替代同步回调解决了浪费CPU性能的问题
- 放在当前宏任务的末尾执行，解决了回调执行的实时性的问题
回调地狱
- 多层嵌套
- 每个任务执行完毕后要分别处理成功和失败这两种可能性
解决方法
- 回调函数延时绑定： 回调函数不是直接声明的，而是在then中传入的，也就是延迟传入
- 返回值穿透： 方便链式调用
- 错误冒泡： 在最后用catch接收到
