摘要：我的博客大家都知道解決了回調(diào)地獄的問題。這就是異步的嵌套帶來的可讀性的問題，它是由異步的運(yùn)行機(jī)制引起的。在與第三方團(tuán)隊(duì)溝通之后問題得到了解決。這不但使代碼變得臃腫不堪，還進(jìn)一步加劇了可讀性的問題。的特征保證了可以解決信任問題。

我的github博客 https://github.com/zhuanyongxigua/blog

大家都知道Promise解決了回調(diào)地獄的問題。說到回調(diào)地獄，很容易想到下面這個(gè)容易讓人產(chǎn)生誤解的圖片：

可回調(diào)地獄到底是什么？它到底哪里有問題？是因?yàn)榍短撞缓每催€是讀起來不方便？

首先我們要想想，嵌套到底哪里有問題？

舉個(gè)例子：

function a() {
  function b() {
    function c() {
      function d() {}
      d();
    }
    c();
  }
  b();
}
a();

這也是嵌套，雖然好像不是特別美觀，可我們并不會(huì)覺得這有什么問題吧？因?yàn)槲覀兘?jīng)常會(huì)寫出類似的代碼。

在這個(gè)例子中的嵌套的問題僅僅是縮進(jìn)的問題，而縮進(jìn)除了會(huì)讓代碼變寬可能會(huì)造成讀代碼的一點(diǎn)不方便之外，并沒有什么其他的問題。如果僅僅是這樣，為什么不叫“縮進(jìn)地獄”或“嵌套地獄”？

把回調(diào)地獄完全理解成縮進(jìn)的問題是常見的對(duì)回調(diào)地獄的誤解。要回到“回調(diào)地獄”這個(gè)詞語上面來，它的重點(diǎn)就在于“回調(diào)”，而“回調(diào)”在JS中應(yīng)用最多的場(chǎng)景當(dāng)然就是異步編程了。

所以，“回調(diào)地獄”所說的嵌套其實(shí)是指異步的嵌套。它帶來了兩個(gè)問題：可讀性的問題和信任問題。

這是一個(gè)在網(wǎng)上隨便搜索的關(guān)于執(zhí)行順序的面試題：

for (var i = 0; i < 5; i++) {
  setTimeout(function() {
    console.log(new Date, i);
  }, 1000);
}

console.log(new Date, i);

答案是什么大家自己想吧，這不是重點(diǎn)。重點(diǎn)是，你要想一會(huì)兒吧？

一個(gè)整潔的回調(diào)：

listen( "click", function handler( evt){ 
  setTimeout( function request(){ 
    ajax( "http:// some. url. 1", function response( text){ 
      if (text == "hello") { 
        handler(); 
      } else if (text == "world") { 
        request(); 
      } 
    }); 
  }, 500); 
});

如果異步的嵌套都是這樣干凈整潔，那“回調(diào)地獄”給程序猿帶來的傷害馬上就會(huì)減少很多。

可我們實(shí)際在寫業(yè)務(wù)邏輯的時(shí)候，真實(shí)的情況應(yīng)該是這樣的：

listen( "click", function handler(evt){ 
  doSomething1();
  doSomething2();
  doSomething3();
  doSomething4();
  setTimeout( function request(){ 
    doSomething8();
    doSomething9();
    doSomething10();
    ajax( "http:// some. url. 1", function response( text){ 
      if (text == "hello") { 
        handler(); 
      } else if (text == "world") { 
        request(); 
      } 
    }); 
    doSomething11();
    doSomething12();
    doSomething13();
  }, 500); 
  doSomething5();
  doSomething6();
  doSomething7();
});

這些“doSomething”有些是異步的，有些是同步。這樣的代碼讀起來會(huì)非常的吃力，因?yàn)槟阋煌５乃伎妓麄兊膱?zhí)行順序，并且還要記在腦袋里面。這就是異步的嵌套帶來的可讀性的問題，它是由異步的運(yùn)行機(jī)制引起的。

這里主要用異步請(qǐng)求討論。我們?cè)谧鯝JAX請(qǐng)求的時(shí)候，一般都會(huì)使用一些第三方的工具庫（即便是自己封裝的，也可以在一定程度上理解成第三方的），這就會(huì)帶來一個(gè)問題：這些工具庫是否百分百的可靠？

一個(gè)來自《YDKJS》的例子：一個(gè)程序員開發(fā)了一個(gè)付款的系統(tǒng)，它良好的運(yùn)行了很長時(shí)間。突然有一天，一個(gè)客戶在付款的時(shí)候信用卡被連續(xù)刷了五次。這名程序員在調(diào)查了以后發(fā)現(xiàn)，一個(gè)第三方的工具庫因?yàn)槟承┰虬迅犊罨卣{(diào)執(zhí)行了五次。在與第三方團(tuán)隊(duì)溝通之后問題得到了解決。

故事講完了，可問題真的解決了嗎？是否還能夠充分的信任這個(gè)工具庫？信任依然要有，可完善必要的檢查和錯(cuò)誤處理勢(shì)在必行。當(dāng)我們解決了這個(gè)問題，由于它的啟發(fā)，我們還會(huì)聯(lián)想到其他的問題，比如沒有調(diào)用回調(diào)。

再繼續(xù)想，你會(huì)發(fā)現(xiàn)，這樣的問題還要好多好多。總結(jié)一下可能會(huì)出現(xiàn)的問題：

回調(diào)過早（一般是異步被同步調(diào)用）；

回調(diào)過晚或沒有回調(diào)；

回調(diào)次數(shù)過多；

等等

加上了這些檢查，強(qiáng)壯之后的代碼可能是這樣的：

listen( "click", function handler( evt){ 
  check1();
  doSomething1();
  setTimeout( function request(){ 
    check2();
    doSomething3();
    ajax( "http:// some. url. 1", function response( text){ 
      if (text == "hello") { 
        handler(); 
      } else if (text == "world") { 
        request(); 
      } 
    }); 
    doSomething4();
  }, 500); 
  doSomething2();
});

我們都清楚的知道，實(shí)際的check要比這里看起來的復(fù)雜的多，而且很多很難復(fù)用。這不但使代碼變得臃腫不堪，還進(jìn)一步加劇了可讀性的問題。

雖然這些錯(cuò)誤出現(xiàn)的概率不大，但我們依然必須要處理。

這就是異步嵌套帶來的信任問題，它的問題的根源在于控制反轉(zhuǎn)?？刂品崔D(zhuǎn)在面向?qū)ο笾械膽?yīng)用是依賴注入，實(shí)現(xiàn)了模塊間的解耦。而在回調(diào)中，它就顯得沒有那么善良了，控制權(quán)被交給了第三方，由第三方?jīng)Q定什么時(shí)候調(diào)用回調(diào)以及如何調(diào)用回調(diào)。

加一個(gè)處理錯(cuò)誤的回調(diào)

function success(data) { 
  console. log(data); 
} 
function failure(err) { 
  console. error( err ); 
} 
ajax( "http:// some. url. 1", success, failure );

nodejs的error-first

function response(err, data) { 
  if (err) { 
    console. error( err ); 
  } 
  else { 
    console. log( data ); 
  } 
} 
ajax( "http:// some. url. 1", response );

這兩種方式解決了一些問題，減少了一些工作量， 但是依然沒有徹底解決問題。首先它們的可復(fù)用性依然不強(qiáng)，其次，如回調(diào)被多次調(diào)用的問題依然無法解決。

Promise已經(jīng)是原生支持的API了，它已經(jīng)被加到了JS的規(guī)范里面，在各大瀏覽器中的運(yùn)行機(jī)制是相同的。這樣就保證了它的可靠。

這一點(diǎn)不用多說，用過Promise的人很容易明白。Promise的應(yīng)用相當(dāng)于給了你一張可以把解題思路清晰記錄下來的草稿紙，你不在需要用腦子去記憶執(zhí)行順序。

Promise并沒有取消控制反轉(zhuǎn)，而是把反轉(zhuǎn)出去的控制再反轉(zhuǎn)一次，也就是反轉(zhuǎn)了控制反轉(zhuǎn)。

這種機(jī)制有點(diǎn)像事件的觸發(fā)。它與普通的回調(diào)的方式的區(qū)別在于，普通的方式，回調(diào)成功之后的操作直接寫在了回調(diào)函數(shù)里面，而這些操作的調(diào)用由第三方控制。在Promise的方式中，回調(diào)只負(fù)責(zé)成功之后的通知，而回調(diào)成功之后的操作放在了then的回調(diào)里面，由Promise精確控制。

Promise有這些特征：只能決議一次，決議值只能有一個(gè)，決議之后無法改變。任何then中的回調(diào)也只會(huì)被調(diào)用一次。Promise的特征保證了Promise可以解決信任問題。

對(duì)于回調(diào)過早的問題，由于Promise只能是異步的，所以不會(huì)出現(xiàn)異步的同步調(diào)用。即便是在決議之前的錯(cuò)誤，也是異步的，并不是會(huì)產(chǎn)生同步（調(diào)用過早）的困擾。

var a = new Promise((resolve, reject) => {
  var b = 1 + c;  // ReferenceError: c is not defined，錯(cuò)誤會(huì)在下面的a打印出來之后報(bào)出。
  resolve(true);
})
console.log(1, a);
a.then(res => {
  console.log(2, res);
})
.catch(err => {
  console.log(err);
})

對(duì)于回調(diào)過晚或沒有調(diào)用的問題，Promise本身不會(huì)回調(diào)過晚，只要決議了，它就會(huì)按照規(guī)定運(yùn)行。至于服務(wù)器或者網(wǎng)絡(luò)的問題，并不是Promise能解決的，一般這種情況會(huì)使用Promise的競(jìng)態(tài)APIPromise.race加一個(gè)超時(shí)的時(shí)間：

function timeoutPromise(delay) {
  return new Promise(function(resolve, reject) {
    setTimeout(function() {
      reject("Timeout!");
    }, delay);
  });
}

Promise.race([doSomething(), timeoutPromise(3000)])
.then(...)
.catch(...);

對(duì)于回調(diào)次數(shù)太少或太多的問題，由于Promise只能被決議一次，且決議之后無法改變，所以，即便是多次回調(diào)，也不會(huì)影響結(jié)果，決議之后的調(diào)用都會(huì)被忽略。

參考資料：

You Don"t Know JS: Async & Performance