如何在專案中合理地使用async / await
1 引言
async / await是ES7的重要特性之一，也是目前社群裡公認的優秀非同步解決方案。目前，async / await這個特性已經是stage 3的建議
然而，由於部分開發人員對該語法糖原理的認識不夠清晰，氾濫而不加考慮地隨意使用async/await ，可能會我們陷入了新的麻煩之中。
2 概述
下面是隨處可見的現代化前端程式碼：
(async () => { const pizzaData = await getPizzaData(); // async call const drinkData = await getDrinkData(); // async call const chosenPizza = choosePizza(); // sync call const chosenDrink = chooseDrink(); // sync call await addPizzaToCart(chosenPizza); // async call await addDrinkToCart(chosenDrink); // async call orderItems(); // async call })();
await 語法本身沒有問題，有時候可能是使用者用錯了。當 pizzaData 與 drinkData 之間沒有依賴時，順序的 await 會最多讓執行時間增加一倍的 getPizzaData 函式時間，因為 getPizzaData 與 getDrinkData應該並行執行。
回到我們吐槽的回撥地獄，雖然程式碼比較醜，帶起碼兩行回撥程式碼並不會帶來阻塞。
看來語法的簡化，帶來了效能問題，而且直接影響到使用者體驗，是不是值得我們反思一下？
正確的做法應該是先同時執行函式，再 await 返回值，這樣可以並行執行非同步函式：
(async () => { const pizzaPromise = selectPizza(); const drinkPromise = selectDrink(); await pizzaPromise; await drinkPromise; orderItems(); // async call })();
或者使用 Promise.all 可以讓程式碼更可讀：
(async () => {
Promise.all([selectPizza(), selectDrink()]).then(orderItems); // async call
})();看來不要隨意的 await，它很可能讓你程式碼效能降低。
3 精讀
仔細思考為什麼 async/await 會被濫用，筆者認為是它的功能比較反直覺導致的。
首先 async/await 真的是語法糖，功能也僅是讓程式碼寫的舒服一些。先不看它的語法或者特性，僅從語法糖三個字，就能看出它一定是侷限了某些能力。
舉個例子，我們利用 html 標籤封裝了一個元件，帶來了便利性的同時，其功能一定是 html 的子集。又比如，某個輪子哥覺得某個元件 api 太複雜，於是基於它封裝了一個語法糖，我們多半可以認為這個便捷性是犧牲了部分功能換來的。
功能完整度與使用便利度一直是相互博弈的，很多框架思想的不同開源版本，幾乎都是把功能完整度與便利度按照不同比例混合的結果。
那麼回到 async/await 它的解決的問題是回撥地獄帶來的災難：
a(() => {
b(() => {
c();
});
});為了減少巢狀結構太多對大腦造成的衝擊，async/await 決定這麼寫：
await a();
await b();
await c();雖然層級上一致了，但邏輯上還是巢狀關係，這不是另一個程度上增加了大腦負擔嗎？而且這個轉換還是隱形的，所以許多時候，我們傾向於忽略它，所以造成了語法糖的濫用。
理解語法糖
雖然要正確理解 async/await 的真實效果比較反人類，但為了清爽的程式碼結構，以及防止寫出低效能的程式碼，還是挺有必要認真理解 async/await 帶來的改變。
首先 async/await 只能實現一部分回撥支援的功能，也就是僅能方便應對層層巢狀的場景。其他場景，就要動一些腦子了。
比如兩對回撥：
a(() => {
b();
});
c(() => {
d();
});如果寫成下面的方式，雖然一定能保證功能一致，但變成了最低效的執行方式：
await a();
await b();
await c();
await d();因為翻譯成回撥，就變成了：
a(() => {
b(() => {
c(() => {
d();
});
});
});然而我們發現，原始程式碼中，函式 c 可以與 a同時執行，但 async/await 語法會讓我們傾向於在 b 執行完後，再執行 c。
所以當我們意識到這一點，可以優化一下效能：
const resA = a();
const resC = c();
await resA;
b();
await resC;
d();但其實這個邏輯也無法達到回撥的效果，雖然 a 與 c 同時執行了，但 d 原本只要等待 c 執行完，現在如果 a 執行時間比 c 長，就變成了:
a(() => {
d();
});看來只有完全隔離成兩個函式：
(async () => {
await a();
b();
})();
(async () => {
await c();
d();
})();或者利用 Promise.all:
async function ab() {
await a();
b();
}
async function cd() {
await c();
d();
}
Promise.all([ab(), cd()]);這就是我想表達的可怕之處。回撥方式這麼簡單的過程式程式碼，換成 async/await 居然寫完還要反思一下，再反推著去優化效能，這簡直比回撥地獄還要可怕。
而且大部分場景程式碼是非常複雜的，同步與 await 混雜在一起，想捋清楚其中的脈絡，並正確優化效能往往是很困難的。但是我們為什麼要自己挖坑再填坑呢？很多時候還會導致忘了填。
原文作者給出了 Promise.all 的方式簡化邏輯，但筆者認為，不要一昧追求 async/await 語法，在必要情況下適當使用回撥，是可以增加程式碼可讀性的。
4 總結
async/await 回撥地獄提醒著我們，不要過渡依賴新特性，否則可能帶來的程式碼執行效率的下降，進而影響到使用者體驗。同時，筆者認為，也不要過渡利用新特性修復新特性帶來的問題，這樣反而導致程式碼可讀性下降。
原文連結戳這裡