共计 4342 个字符，预计需要花费 11 分钟才能阅读完成。
久经前端开发沙场，会经历各式各样的需求，处理这些需求时候，会使用各种各样的 api 和功能，这里集中对 setTimeout 和 Promise 的异步功能进行讨论一下。
单独使用的执行模式
这里就使用 Promise 作为例子，来探究一下单独使用它，会有哪些注意点。
1. 最初的试探
执行代码，Promise 的基本使用：
let fn = () => {
console.log(1)
let a = new Promise((resolve, reject) => {
console.log(2)
resolve(3)
})
console.log(4)
return a
}
// 执行
fn().then(data => console.log(data))
以上代码，输出结果为：
1 // 同步
2 // 同步
4 // 同步
3 // 异步
注意 new Promise() 是同步方法，resolve 才是异步方法。此外，上面的方法，可以有下面这种写法，效果等同，主要是把 Promise 精简了一下：
let fn = () => {
console.log(1)
console.log(2)
let a = Promise.resolve(3)
console.log(4)
return a
}
// 执行
fn().then(data => console.log(data))
因为现在讨论的是 Promise 的异步功能，所以下面均使用第二种写法的 Promise
2. 多个同级 Promise
编辑器中，输入以下代码，多个同级的单层的 Promise：
console.log(‘ 同步 -0.1’)
Promise.resolve().then(() => {
console.log(‘P-1.1’)
})
Promise.resolve().then(() => {
console.log(‘P-1.2’)
})
Promise.resolve().then(() => {
console.log(‘P-1.3’)
})
console.log(‘ 同步 -0.2’)
则会依次输出以下打印，毫无疑问的结果：
同步 -0.1
同步 -0.2
P-1.1
P-1.2
P-1.3
3.Promise 套 Promise
复杂一下，新增行有注释说明：
console.log(‘ 同步 -0.1’)
Promise.resolve().then(() => {
console.log(‘P-1.1’)
Promise.resolve().then(() => {// 新加行
console.log(‘P-2.1’) // 新加行
}) // 新加行
})
Promise.resolve().then(() => {
console.log(‘P-1.2’)
Promise.resolve().then(() => {// 新加行
console.log(‘P-2.2’) // 新加行
}) // 新加行
})
Promise.resolve().then(() => {
console.log(‘P-1.3’)
Promise.resolve().then(() => {// 新加行
console.log(‘P-2.3’) // 新加行
}) // 新加行
})
console.log(‘ 同步 -0.2’)
输出结果如下：
同步 -0.1
同步 -0.2
P-1.1
P-1.2
P-1.3
P-2.1
P-2.2
P-2.3
可见，多层 Promise 是一层一层执行的。
4. 为了最终确认，进行最后一次验证，在第一个 Promise 里面多加一层：
console.log(‘ 同步 -0.1’)
Promise.resolve().then(() => {
console.log(‘P-1.1’)
Promise.resolve().then(() => {
console.log(‘P-2.1’)
Promise.resolve().then(() => {// 新加行
console.log(‘P-3.1’) // 新加行
}) // 新加行
Promise.resolve().then(() => {// 新加行
console.log(‘P-3.2’) // 新加行
}) // 新加行
})
})
Promise.resolve().then(() => {
console.log(‘P-1.2’)
Promise.resolve().then(() => {
console.log(‘P-2.2’)
})
})
Promise.resolve().then(() => {
console.log(‘P-1.3’)
Promise.resolve().then(() => {
console.log(‘P-2.3’)
})
})
console.log(‘ 同步 -0.2’)
输出结果如下：
同步 -0.1
同步 -0.2
P-1.1
P-1.2
P-1.3
P-2.1
P-2.2
P-2.3
P-3.1
P-3.2
确认完毕，的确是一层一层的执行。
而且这里可以告诉大家，setTimeout 和 setInterval 在单独使用的时候，和 Promise 是一样的，同样是分层执行，这里不再贴代码了（友情提醒：setInterval 的话，需要第一次执行就把这个定时器清掉，否则就无限执行，卡死页面秒秒钟的事儿）,
混合使用的执行模式
接下来才是重点，下面将 setTimeout 和 Promise 进行混合操作。
console.log(‘ 同步 -0.1’)
Promise.resolve().then(() => {
console.log(‘P-1.1’)
})
setTimeout(() => {
console.log(‘S-1.1’)
});
Promise.resolve().then(() => {
console.log(‘P-1.2’)
})
setTimeout(() => {
console.log(‘S-1.2’)
});
console.log(‘ 同步 -0.2’)
执行结果如下。。。问题暴露出来了：
同步 -0.1
同步 -0.2
P-1.1
P-1.2
S-1.1
S-1.2
为什么，在同级情况下，是 Promise 执行完了 setTimeout 才会执行？
是人性的泯灭，还是道德的沦丧？
是因为 JavaScript 任务类型！
JavaScript 的微任务和宏任务
敲黑板，标重点。
JavaScript 的任务分为微任务（Microtasks）和宏任务（task）；
宏任务是主流，当 js 开始被执行的时候，就是开启一个宏任务，在宏任务中执行一条一条的指令；
宏任务可以同时有多个，但会按顺序一个一个执行；
每一个宏任务，后面都可以跟一个微任务队列，如果微任务队列中有指令或方法，那么就会执行；如果没有，则开始执行下一个宏任务，直到所有的宏任务执行完为止，微任务相当于宏任务的小尾巴；
为什么有了宏任务，还会有微任务存在？因为宏任务太占用性能，当需要一些较早就准备好的方法，排在最后才执行的时候，又不想新增一个宏任务，那么就可以把这些方法，一个一个的放在微任务队列里面，在这个宏任务中的代码执行完后，就会执行微任务队列。
而 Promise 是微任务，setTimeout 是宏任务。
所以上面的代码中，代码执行时会是如下场景：
开始执行当前宏任务代码！遇到了 Promise？好嘞，把它里面的异步代码，放在当前这个宏任务后面微任务里面，然后继续执行咱的；
咦，有个 setTimeout？是个宏任务，那在当前这个宏任务后面，创建第二个宏任务，然后把这个 setTimeout 里面的代码塞进去，咱继续执行；
咦，又一个 Promise？把他塞进后面的微任务里。。。什么？已经有代码了？那有啥关系，继续往里塞，放在已有代码的后面就行，咱继续执行；
天啊，又来一个 setTimeout，现在后面已经有第二个宏任务了对吧？那就创建第三个宏任务吧，后面再遇到的话，继续创建；
报告！代码执行到底了，当前这个宏任务执行完毕！行，看一下咱的小尾巴 — 咱的微任务里面有代码吗？有的话直接执行；
报告，微任务里面，那两个 Promise 的异步代码执行完了！干的漂亮。。。对了，刚刚微任务里面，有没有新的 Promise 微任务？有的话，继续在现在这个微任务后面放！对对，只看执行到的代码，有多少放多少，一会儿直接就执行了。。。如果遇到了 setTimeout 知道该怎么做吧？继续开宏任务！
报告，微任务全部执行完毕！
好！开始执行下一个宏任务！
所以，现在如果执行下面的代码，结果也显而易见吧：
console.log(‘ 同步 -0.1’)
Promise.resolve().then(() => {
console.log(‘P-1.1’)
Promise.resolve().then(() => {// 新加行
console.log(‘P-2.1’) // 新加行
Promise.resolve().then(() => {// 新加行
console.log(‘P-3.1’) // 新加行
}) // 新加行
}) // 新加行
})
setTimeout(() => {
console.log(‘S-1.1’)
});
Promise.resolve().then(() => {
console.log(‘P-1.2’)
})
setTimeout(() => {
console.log(‘S-1.2’)
});
console.log(‘ 同步 -0.2’)
执行结果如下：
同步 -0.1
同步 -0.2
P-1.1
P-1.2
P-2.1
P-3.1
S-1.1
S-1.2
无论 Promise 套用多少层，都会在下一个 setTimeout 之前执行。
Dom 操作到底是同步，还是异步？
这里出现一个说不清道不明的疑问，Dom 操作到底是同步操作还是异步操作？
如果是同步操作，那 vue 的 nextTick 方法是做什么用的？不就是在 Dom 更新完之后的回调方法吗？
如果是异步操作，那在剧烈操作 Dom 后面的代码，为什么会被阻塞？而且代码看上去，也的确是按顺序执行的？
这里直接说明：js 里面的 Dom 操作代码，是同步执行，但浏览器进行的 Dom 渲染，是异步操作。
浏览器渲染 Dom 和执行 js，同时只能二选一，渲染一次 Dom 的时机是，当前宏任务和小尾巴微任务执行完，下一个宏任务开始前
vue 的 nextTick 方法，则是使用 H5 的 Api—MutationObserver，监听浏览器将 Dom 渲染完成的时机。若浏览器不支持此方法，则会使用 setTimeout，把 nextTick 回调函数的执行时机，作为一个宏任务；
上面也说了，浏览器渲染一次 Dom，是下一个宏任务开始前，这样使用了 setTimeout，保证了 Dom 确实渲染完成。
这里也需要稍作提醒，js 操作 Dom 是同步的，但操作 Dom，毕竟超出了 js 本身语言的 Api，每操作一次 Dom，都需要消耗一定的性能，所以，在适合的情况下，最好先把要修改的 Dom 的内容，以字符串或者虚拟 Dom 的形式拼接好，然后操作一次 Dom，把组装好的 Dom 字符串或虚拟 Dom，一次性的塞进 HTML 页面的真实 Dom 中。
