[[320125]]

關(guān)于 JS 單線程、EventLoop 以及異步 I/O 這些底層的特性，我們之前做過了詳細的拆解，不在贅述。在探究了底層機制之后，我們還需要對代碼的組織方式有所理解，這是離我們最日常開發(fā)最接近的部分，異步代碼的組織方式直接決定了開發(fā)和維護的效率，其重要性也不可小覷。盡管底層機制沒變，但異步代碼的組織方式卻隨著 ES 標準的發(fā)展，一步步發(fā)生了巨大的變革。接著讓我們來一探究竟吧!

回調(diào)函數(shù)時代

相信很多 nodejs 的初學者都或多或少踩過這樣的坑，node 中很多原生的 api 就是諸如這樣的:

fs.readFile('xxx', (err, data) => { 
 
}); 

典型的高階函數(shù)，將回調(diào)函數(shù)作為函數(shù)參數(shù)傳給了readFile。但久而久之，就會發(fā)現(xiàn)，這種傳入回調(diào)的方式也存在大坑, 比如下面這樣:

fs.readFile('1.json', (err, data) => { 
    fs.readFile('2.json', (err, data) => { 
        fs.readFile('3.json', (err, data) => { 
            fs.readFile('4.json', (err, data) => { 
 
            }); 
        }); 
    }); 
}); 

回調(diào)當中嵌套回調(diào)，也稱回調(diào)地獄。這種代碼的可讀性和可維護性都是非常差的，因為嵌套的層級太多。而且還有一個嚴重的問題，就是每次任務(wù)可能會失敗，需要在回調(diào)里面對每個任務(wù)的失敗情況進行處理，增加了代碼的混亂程度。

Promise 時代

ES6 中新增的 Promise 就很好了解決了回調(diào)地獄的問題，同時了合并了錯誤處理。寫出來的代碼類似于下面這樣:

readFilePromise('1.json').then(data => { 
    return readFilePromise('2.json') 
}).then(data => { 
    return readFilePromise('3.json') 
}).then(data => { 
    return readFilePromise('4.json') 
}); 

以鏈式調(diào)用的方式避免了大量的嵌套，也符合人的線性思維方式，大大方便了異步編程。

co + Generator 方式

利用協(xié)程完成 Generator 函數(shù)，用 co 庫讓代碼依次執(zhí)行完，同時以同步的方式書寫，也讓異步操作按順序執(zhí)行。

co(function* () { 
  const r1 = yield readFilePromise('1.json'); 
  const r2 = yield readFilePromise('2.json'); 
  const r3 = yield readFilePromise('3.json'); 
  const r4 = yield readFilePromise('4.json'); 
}) 

async + await方式

這是 ES7 中新增的關(guān)鍵字，凡是加上 async 的函數(shù)都默認返回一個 Promise 對象，而更重要的是 async + await 也能讓異步代碼以同步的方式來書寫，而不需要借助第三方庫的支持。

const readFileAsync = async function () { 
  const f1 = await readFilePromise('1.json') 
  const f2 = await readFilePromise('2.json') 
  const f3 = await readFilePromise('3.json') 
  const f4 = await readFilePromise('4.json') 
} 

這四種經(jīng)典的異步編程方式就簡單回顧完了，由于是鳥瞰大局，我覺得知道是什么比了解細節(jié)要重要, 因此也沒有展開。不過沒關(guān)系，接下來，讓我們針對這些具體的解決方案，一步步深入異步編程，理解其中的本質(zhì)。