我们有时候需要遍历数组的元素，将它们传入到异步函数中执行，其中的异步写法容易写错，我们来看一下有哪些易错点。
假设我们有个异步方法 sleepPromise，形式如下：
这里为了方便演示，使用 setTimeout 写成了个 promise 形式的 sleep 方法。传入的 t 为延迟执行的时间，msg 为信息内容。
在实际开发中，异步方法可能是传入用户好友 id 查找数据库，获得简单的好友信息。
假设我们需要在下面代码的注释位置下方写一个异步便利实现。
通常前端一看到要遍历数组，就会用 forEach。如果你不够老道，可能会写出如下的实现：
输出结果为；
这种写法并不对，其实是将遍历写成了同步。
问题出在哪？出在 forEach 本身并不支持异步写法，你在 forEach 方法的前面加不加 await 关键字都是无效的，因为它的内部没有处理异步的逻辑。
forEach 是 ES5 的 API，要比 ES6 的 Promise 要早的多得多。为了向后兼容，forEach 以后也不会支持异步处理。
所以 forEach 的执行并不会阻塞 loopAsync 之后的代码，所以会导致阻塞失败，先输出 [end]。
使用普通的 for 循环写法，await 的外层函数就仍就是 loopAysnc 方法，就能正确保存阻塞代码。
但这里的问题是，这些异步方法的执行是 串行 的。可以看到总共执行了 6 s。
如果我们的这些请求是有顺序的依赖关系的，这样写是没问题。
但如果我们的场景是根据用户 id 数组从数据库中查找对应用户名，我们的时间复杂度就是 O(n) ，是不合理的。
此时我们需要改写为 并行 的异步，并且还要保证所有异步都执行完后才执行下一步。我们可以用 Promise.all()。
首先，我们需要根据 tasks 数组生成对应的 promise 对象数组，然后传入到 Promise.all 方法中执行。
这样，这些异步方法就会同时执行。当所有异步都执行完毕后，代码才往下执行。
输出结果如下：
3 秒就完事了，太强了。
前面说到 forEach 底层并没有实现异步的处理，才导致阻塞失效，那么我们其实不妨实现支持异步的简易 forEach。
并行实现：
串行实现：
用法：
简单总结一下。
一般来说，我们更常用 Promise.all 的并行执行异步的方法，常见于数据库查找一些 id 对应的数据的场景。
for 循环的串行写法适用于多个异步有依赖的情况，比如找最终推荐人。
forEach 则是纯粹的错误写法，除非是不需要使用 async/await 的情况。
按照js同步执行的顺序，函数调用会首先执行for循环，循环5次开启了5个延迟器，延时器内部的回调函数将会异步执行，会在延时1s后进入消息队列等待执行。循环了5次，所以此时i的值为5，然后同步执行console.log打印5，第一次同步执行结束，然后开始执行消息队列的异步任务，打印5个5，中间的undefined是函数调用无返回值返回的。
执行顺序和第一题相同，不同的是延时器被包裹在了一个立即执行函数内容，并把每一次循环的i作为参数传入，此时循环内部的函数形成了一个私有作用域，每一次的i变量被独立保存了起来，因此每一次循环的i的值都会被打印出来。
延时器内部回调函数是异步函数，将在延时结束后，进入消息队列等待执行，因此同步的console.log("CCCC")最优先执行，然后延时0ms的延时器的回调先进入消息队列，1000ms后第一个延时器的回调再进入消息队列等待执行，因此先执行0ms的回调打印DDDD，再执行1000ms的回调打印BBBB。
这里与上一题不同的是中间多了一个执行3s的同步while循环，因此执行顺序是这样的：
第一个延时器延时1s后内部异步回调函数进入消息队列等待执行，
等待while循环3s后打印"CCCC"，
循环结束后第一个延时器内部的回调已经进入消息队列第一个执行位置等待执行。
第二个延时器延时0s后内部异步回调函数进入消息队列等待执行，延时结束后排到第一个延时器的回调函数后面，
因此异步队里内部先打印"BBBB"，再打印"DDDD"
