在寫Node.js的過程中，連續的IO操作可能會導致“金字塔噩夢”，回調函數的多重嵌套讓代碼變的難以維護，利用CommonJs的Promise來封裝異步函數，使用統一的鏈式API來擺脫多重回呼的惡夢。
Node.js提供的非阻塞IO模型允許我們利用回調函數的方式處理IO操作，但是當需要連續的IO操作時，你的回調函數會多重嵌套，程式碼很不美觀，而且不易維護，而且可能會有許多錯誤處理的重複程式碼，也就是所謂的「Pyramid of Doom」。
什麼是Promise？
CommonJs的Promise規範有許多種，我們一般討論的是Promise/A 規範，它定義了Promise的基本行為。
Promise是一個對象，它通常代表一個在未來可能完成的非同步操作。這個操作可能成功也可能失敗，所以一個Promise物件一般有3個狀態：Pending，Fulfilled，Rejected。分別代表未完成、成功完成和操作失敗。一旦Promise物件的狀態從Pending變成Fulfilled或Rejected任一個，它的狀態都沒有辦法再被改變。
一個Promise物件通常會有一個then方法，這個方法讓我們可以去操作未來可能成功後回傳的值或是失敗的原因。這個then方法是這樣子的：
promise.then(onFulfilled, onRejected)
顯而易見的是，then方法接受兩個參數，它們通常是兩個函數，一個是用來處理操作成功後的結果的，另一個是用來處理操作失敗後的原因的，這兩個函數的第一個參數分別是成功後的結果和失敗的原因。如果傳給then方法的不是一個函數，那麼這個參數就會被忽略。
then方法的回傳值是一個Promise對象，這一個特點允許我們鍊式呼叫then來達到控制流程的效果。這裡有許多細節上的問題，例如值的傳遞或錯誤處理等。 Promise的規範是這樣定義的：
onFulfilled或onRejected函數的回傳值不是Promise對象，則該值將會作為下一個then方法中onFulfilled的第一個參數，如果傳回值是一個Promise對象，怎麼then方法的回傳值就是該Promise對象
onFulfilled或onRejected函數中如果有異常拋出，則該then方法的回傳的Promise物件狀態轉為Rejected，如果該Promise物件呼叫then，則Error物件會作為onRejected函數的第一個參數
如果Promise狀態變成Fulfilled而在then方法中沒有提供onFulfilled函數，則then方法傳回的Promise物件狀態變成Fulfilled且成功的結果為上一個Promise的結果，Rejected同理。
補充一句，onFulfilled和onRejected都是非同步執行的。
規範的實作：q
上面講的是Promise的規範，而我們需要的是它的實現，q是一個對Promise/A 有著較好實現規範的函式庫。
首先我們需要創建一個Promise對象，關於Promise對象創建的規範在Promise/B中，這裡不做詳細的解釋，直接上代碼。
多數Promise的實作在Promise的建立上大同小異，透過建立一個具有promise屬性的defer對象，如果成功取得到值則呼叫defer.resolve(value)，如果失敗，則呼叫defer.reject(reason)，最後回傳defer的promise屬性即可。這個過程可以理解為呼叫defer.resolve將Promise的狀態變成Fulfilled，呼叫defer.reject將Promise的狀態變成Rejected。
在面對一系列連續的非同步方法時，怎麼利用Promise寫出漂亮的程式碼呢？看下下面的例子。
在上面的程式碼中，then方法只接受OnFulfilled，而catch方法實際上就是then(null, OnRejected)，這樣的話只要一系列非同步方法只要總是成功回傳值的，那麼程式碼就會瀑布式的向下運行，如果其中任一個非同步方法失敗或發生異常，那麼根據CommonJs的Promise規範，將執行catch中的function。 q也提供了finally方法，從字面上也很好理解，就是不論resolve還是reject，最後都會執行finally中的function。
看起來似乎不錯，程式碼更以維護且美觀了，那麼如果希望並發呢？
q也為並發提供了api，呼叫all方法並傳遞一個Promise數組即可繼續使用then的鍊式風格。還有像q.nfbind等可以將Node.js的原生API轉換成Promise來統一程式碼格式也是挺好的。更多api在這裡就不一一詳述了。
結論
本文主要介紹透過使用Promise來解決Node.js控制流問題，但Promise也可同樣應用於前端，EMCAScript6已經提供了原生的API支援。需要指出的是Promise並不是唯一的解決方案，async也是一個很好的選擇，並且提供更友好的並發控制API，不過我覺得Promise在封裝具有非同步方法的函數時更具優勢。
好了，本文就先到這裡了，希望對大家能夠有所幫助。
