眾所周知，老板可以給高層或領(lǐng)導(dǎo)們畫餅，而領(lǐng)導(dǎo)們拿著老板畫的餅，也必須給底下員工繼續(xù)畫餅，讓打工人們雞血不停，這樣大家的餅才都有可能兌現(xiàn)。

這種自上而下發(fā)餅的行為與Promise的鏈?zhǔn)秸{(diào)用在思路上不謀而合。

bossBing.then( 
  success => { 
    // leader接過boss的餅，繼續(xù)往下面發(fā)餅 
    return leaderBing 
  } 
).then( 
  success => { 
    console.log('leader畫的餅真的實現(xiàn)了，別墅靠海') 
  }, 
  fail => { 
    console.log('leader畫的餅炸了，以淚洗面...') 
  } 
) 

總體來說，Promise與現(xiàn)實世界的承諾還是挺相似的。

而Promise在具體實現(xiàn)上還有很多細(xì)節(jié)，比如異步處理的細(xì)節(jié)，Resolution算法，等等，這些在后面都會講到。下面我會從自己對Promise的第一印象講起，繼而過渡到對宏任務(wù)與微任務(wù)的認(rèn)識，最終揭開Promise/A+規(guī)范的神秘面紗。

初識Promise

還記得最早接觸Promise的時候，我感覺能把a(bǔ)jax過程封裝起來就挺“厲害”了。那個時候?qū)romise的印象大概就是：優(yōu)雅的異步封裝，不再需要寫高耦合的callback。

這里臨時手?jǐn)]一個簡單的ajax封裝作為示例說明：

function isObject(val) { 
  return Object.prototype.toString.call(val) === '[object Object]'; 
} 
 
function serialize(params) { 
    let result = ''; 
    if (isObject(params)) { 
      Object.keys(params).forEach((key) => { 
        let val = encodeURIComponent(params[key]); 
        result += `${key}=${val}&`; 
      }); 
    } 
    return result; 
} 
 
const defaultHeaders = { 
  "Content-Type": "application/x-www-form-urlencoded" 
} 
 
// ajax簡單封裝 
function request(options) { 
  return new Promise((resolve, reject) => { 
    const { method, url, params, headers } = options 
    const xhr = new XMLHttpRequest(); 
    if (method === 'GET' || method === 'DELETE') { 
      // GET和DELETE一般用querystring傳參 
      const requestURL = url + '?' + serialize(params) 
      xhr.open(method, requestURL, true); 
    } else { 
      xhr.open(method, url, true); 
    } 
    // 設(shè)置請求頭 
    const mergedHeaders = Object.assign({}, defaultHeaders, headers) 
    Object.keys(mergedHeaders).forEach(key => { 
      xhr.setRequestHeader(key, mergedHeaders[key]); 
    }) 
    // 狀態(tài)監(jiān)聽 
    xhr.onreadystatechange = function () { 
      if (xhr.readyState === 4) { 
        if (xhr.status === 200) { 
          resolve(xhr.response) 
        } else { 
          reject(xhr.status) 
        } 
      } 
    } 
    xhr.onerror = function(e) { 
      reject(e) 
    } 
    // 處理body數(shù)據(jù)，發(fā)送請求 
    const data = method === 'POST' || method === 'PUT' ? serialize(params) : null 
    xhr.send(data); 
  }) 
} 
 
const options = { 
  method: 'GET', 
  url: '/user/page', 
  params: { 
    pageNo: 1, 
    pageSize: 10 
  } 
} 
// 通過Promise的形式調(diào)用接口 
request(options).then(res => { 
  // 請求成功 
}, fail => { 
  // 請求失敗 
}) 

以上代碼封裝了ajax的主要過程，而其他很多細(xì)節(jié)和各種場景覆蓋就不是幾十行代碼能說完的。不過我們可以看到，Promise封裝的核心就是：

• 封裝一個函數(shù)，將包含異步過程的代碼包裹在構(gòu)造Promise的executor中，所封裝的函數(shù)最后需要return這個Promise實例。
• Promise有三種狀態(tài)，Pending, Fulfilled, Rejected。而resolve(), reject()是狀態(tài)轉(zhuǎn)移的觸發(fā)器。
• 確定狀態(tài)轉(zhuǎn)移的條件，在本例中，我們認(rèn)為ajax響應(yīng)且狀態(tài)碼為200時，請求成功(執(zhí)行resolve())，否則請求失敗(執(zhí)行reject())。

ps: 實際業(yè)務(wù)中，除了判斷HTTP狀態(tài)碼，我們還會另外判斷內(nèi)部錯誤碼(業(yè)務(wù)系統(tǒng)中前后端約定的狀態(tài)code)。

實際上現(xiàn)在有了axios這類的解決方案，我們也不會輕易選擇自行封裝ajax，不鼓勵重復(fù)造這種基礎(chǔ)且重要的輪子，更別說有些場景我們往往難以考慮周全。當(dāng)然，在時間允許的情況下，可以學(xué)習(xí)其源碼實現(xiàn)。

宏任務(wù)與微任務(wù)

要理解Promise/A+規(guī)范，必須先溯本求源，Promise與微任務(wù)息息相關(guān)，所以我們有必要先對宏任務(wù)和微任務(wù)有個基本認(rèn)識。

在很長一段時間里，我都沒有太多去關(guān)注宏任務(wù)(Task)與微任務(wù)(Microtask)。甚至有一段時間，我覺得setTimeout(fn, 0)在操作動態(tài)生成的DOM元素時非常好用，然而并不知道其背后的原理，實質(zhì)上這跟Task聯(lián)系緊密。

var button = document.createElement('button'); 
button.innerText = '新增輸入框' 
document.body.append(button) 
 
button.onmousedown = function() { 
  var input = document.createElement('input'); 
  document.body.appendChild(input); 
  setTimeout(function() { 
    input.focus(); 
  }, 0) 
} 

如果不使用setTimeout 0，focus()會沒有效果。

那么，什么是宏任務(wù)和微任務(wù)呢?我們慢慢來揭開答案。

現(xiàn)代瀏覽器采用多進(jìn)程架構(gòu)，這一點可以參考Inside look at modern web browser[4]。而和我們前端關(guān)系最緊密的就是其中的Renderer Process，Javascript便是運(yùn)行在Renderer Process的Main Thread中。

Renderer: Controls anything inside of the tab where a website is displayed.

渲染進(jìn)程控制了展示在Tab頁中的網(wǎng)頁的一切事情。可以理解為渲染進(jìn)程就是專門為具體的某個網(wǎng)頁服務(wù)的。

我們知道，Javascript可以直接與界面交互。假想一下，如果Javascript采用多線程策略，各個線程都能操作DOM，那最終的界面呈現(xiàn)到底以誰為準(zhǔn)呢?這顯然是存在矛盾的。因此，Javascript選擇使用單線程模型的一個重要原因就是：為了保證用戶界面的強(qiáng)一致性。

為了保證界面交互的連貫性和平滑度，Main Thread中，Javascript的執(zhí)行和頁面的渲染會交替執(zhí)行(出于性能考慮，某些情況下，瀏覽器判斷不需要執(zhí)行界面渲染，會略過渲染的步驟)。目前大多數(shù)設(shè)備的屏幕刷新率為60次/秒，1幀大約是16.67ms，在這1幀的周期內(nèi)，既要完成Javascript的執(zhí)行，還要完成界面的渲染(if necessary)，利用人眼的殘影效應(yīng)，讓用戶覺得界面交互是非常流暢的。

用一張圖看看1幀的基本過程，引用自https://aerotwist.com/blog/the-anatomy-of-a-frame/

PS：requestIdleCallback是空閑回調(diào)，在1幀的末尾，如果還有時間富余，就會調(diào)用requestIdleCallback。注意不要在requestIdleCallback中修改DOM，或者讀取布局信息導(dǎo)致觸發(fā)Forced Synchronized Layout，否則會引發(fā)性能和體驗問題。具體見Using requestIdleCallback[5]。

我們知道，一個網(wǎng)頁中的Render Process只有一個Main Thread，本質(zhì)上來說，Javascript的任務(wù)在執(zhí)行階段都是按順序執(zhí)行，但是JS引擎在解析Javascript代碼時，會把代碼分為同步任務(wù)和異步任務(wù)。同步任務(wù)直接進(jìn)入Main Thread執(zhí)行;異步任務(wù)進(jìn)入任務(wù)隊列，并關(guān)聯(lián)著一個異步回調(diào)。

在一個web app中，我們會寫一些Javascript代碼或者引用一些腳本，用作應(yīng)用的初始化工作。在這些初始代碼中，會按照順序執(zhí)行其中的同步代碼。而在這些同步代碼執(zhí)行的過程中，會陸陸續(xù)續(xù)監(jiān)聽一些事件或者注冊一些異步API(網(wǎng)絡(luò)相關(guān)，IO相關(guān)，等等...)的回調(diào)，這些事件處理程序和回調(diào)就是異步任務(wù)，異步任務(wù)會進(jìn)入任務(wù)隊列，并且在接下來的Event Loop中被處理。

異步任務(wù)又分為Task和Microtask，各自有單獨的數(shù)據(jù)結(jié)構(gòu)和內(nèi)存來維護(hù)。

用一個簡單的例子來感受下：

var a = 1; 
console.log('a:', a) 
var b = 2; 
console.log('b:', b) 
setTimeout(function task1(){ 
  console.log('task1:', 5) 
  Promise.resolve(6).then(function microtask2(res){ 
    console.log('microtask2:', res) 
  }) 
}, 0) 
Promise.resolve(4).then(function microtask1(res){ 
  console.log('microtask1:', res) 
}) 
var b = 3; 
console.log('c:', c) 

以上代碼執(zhí)行后，依次在控制臺輸出：

a: 1 
b: 2 
c: 3 
microtask1: 4 
task1: 5 
microtask2: 6 

仔細(xì)一看也沒什么難的，但是這背后發(fā)生的細(xì)節(jié)，還是有必要探究下。我們不妨先問自己幾個問題，一起來看下吧。

Task和Microtask都有哪些?

• Tasks：
  • setTimeout
  • setInterval
  • MessageChannel
  • I/0(文件，網(wǎng)絡(luò))相關(guān)API
  • DOM事件監(jiān)聽：瀏覽器環(huán)境
  • setImmediate：Node環(huán)境，IE好像也支持(見caniuse數(shù)據(jù))
• Microtasks:
  • requestAnimationFrame：瀏覽器環(huán)境
  • MutationObserver：瀏覽器環(huán)境
  • Promise.prototype.then, Promise.prototype.catch, Promise.prototype.finally
  • process.nextTick：Node環(huán)境
  • queueMicrotask

requestAnimationFrame是不是微任務(wù)?

requestAnimationFrame簡稱rAF，經(jīng)常被我們用來做動畫效果，因為其回調(diào)函數(shù)執(zhí)行頻率與瀏覽器屏幕刷新頻率保持一致，也就是我們通常說的它能實現(xiàn)60FPS的效果。在rAF被大范圍應(yīng)用前，我們經(jīng)常使用setTimeout來處理動畫。但是setTimeout在主線程繁忙時，不一定能及時地被調(diào)度，從而出現(xiàn)卡頓現(xiàn)象。

那么rAF屬于宏任務(wù)或者微任務(wù)嗎?其實很多網(wǎng)站都沒有給出定義，包括MDN上也描述得非常簡單。

我們不妨自己問問自己，rAF是宏任務(wù)嗎?我想了一下，顯然不是，rAF可以用來代替定時器動畫，怎么能和定時器任務(wù)一樣被Event Loop調(diào)度呢?

我又問了問自己，rAF是微任務(wù)嗎?rAF的調(diào)用時機(jī)是在下一次瀏覽器重繪之前，這看起來和微任務(wù)的調(diào)用時機(jī)差不多，曾讓我一度認(rèn)為rAF是微任務(wù)，而實際上rAF也不是微任務(wù)。為什么這么說呢?請運(yùn)行下這段代碼。

function recursionRaf() { 
 requestAnimationFrame(() => { 
        console.log('raf回調(diào)') 
        recursionRaf() 
    }) 
} 
recursionRaf(); 

你會發(fā)現(xiàn)，在無限遞歸的情況下，rAF回調(diào)正常執(zhí)行，瀏覽器也可正常交互，沒有出現(xiàn)阻塞的現(xiàn)象。

而如果rAF是微任務(wù)的話，則不會有這種待遇。不信你可以翻到后面一節(jié)內(nèi)容「如果Microtask執(zhí)行時又創(chuàng)建了Microtask，怎么處理?」。

所以，rAF的任務(wù)級別是很高的，擁有單獨的隊列維護(hù)。在瀏覽器1幀的周期內(nèi)，rAF與Javascript執(zhí)行，瀏覽器重繪是同一個Level的。(其實，大家在前面那張「解剖1幀」的圖中也能看出來了。)

Task和Microtask各有1個隊列?

最初，我認(rèn)為既然瀏覽器區(qū)分了Task和Microtask，那就只要各自安排一個隊列存儲任務(wù)即可。事實上，Task根據(jù)task source的不同，安排了獨立的隊列。比如Dom事件屬于Task，但是Dom事件有很多種類型，為了方便user agent細(xì)分Task并精細(xì)化地安排各種不同類型Task的處理優(yōu)先級，甚至做一些優(yōu)化工作，必須有一個task source來區(qū)分。同理，Microtask也有自己的microtask task source。

具體解釋見HTML標(biāo)準(zhǔn)中的一段話：

Essentially, task sources are used within standards to separate logically-different types of tasks, which a user agent might wish to distinguish between. Task queues *are used by user agents to coalesce task sources within a given event loop。

Task和Microtask的消費機(jī)制是怎樣的?

An event loop has one or more task queues. A task queue is a set of tasks.

javascript是事件驅(qū)動的，所以Event Loop是異步任務(wù)調(diào)度的核心。雖然我們一直說任務(wù)隊列，但是Tasks在數(shù)據(jù)結(jié)構(gòu)上不是隊列(Queue)，而是集合(Set)。在每一輪Event Loop中，會取出第一個runnable的Task(第一個可執(zhí)行的Task，并不一定是順序上的第一個Task)進(jìn)入Main Thread執(zhí)行，然后再檢查Microtask隊列并執(zhí)行隊列中所有Microtask。

說再多，都不如一張圖直觀，請看!

Task和Microtask什么時候進(jìn)入相應(yīng)隊列?

回過頭來看，我們一直在提這個概念“異步任務(wù)進(jìn)入隊列”，那么就有個疑問，Task和Microtask到底是什么時候進(jìn)入相應(yīng)的隊列?我們重新來捋捋。異步任務(wù)有注冊，進(jìn)隊列，回調(diào)被執(zhí)行這三個關(guān)鍵行為。注冊很好理解，代表這個任務(wù)被創(chuàng)建了;而回調(diào)被執(zhí)行則代表著這個任務(wù)已經(jīng)被主線程撈起并執(zhí)行了。但是，在進(jìn)隊列這一行為上，宏任務(wù)和微任務(wù)的表現(xiàn)是不一樣的。

宏任務(wù)進(jìn)隊列

對于Task而言，任務(wù)注冊時就會進(jìn)入隊列，只是任務(wù)的狀態(tài)還不是runnable，不具備被Event Loop撈起的條件。

我們先用Dom事件為例舉個例子。

document.body.addEventListener('click', function(e) { 
    console.log('被點擊了', e) 
}) 

當(dāng)addEventListener這行代碼被執(zhí)行時，任務(wù)就注冊了，代表有一個用戶點擊事件相關(guān)的Task進(jìn)入任務(wù)隊列。那么這個宏任務(wù)什么時候才變成runnable呢?當(dāng)然是用戶點擊發(fā)生并且信號傳遞到瀏覽器Render Process的Main Thread后，此時宏任務(wù)變成runnable狀態(tài)，才可以被Event Loop撈起，進(jìn)入Main Thread執(zhí)行。

這里再舉個例子，順便解釋下為什么setTimeout 0會有延遲。

setTimeout(function() { 
 console.log('我是setTimeout注冊的宏任務(wù)') 
}, 0) 

執(zhí)行setTimeout這行代碼時，相應(yīng)的宏任務(wù)就被注冊了，并且Main Thread會告知定時器線程，“你定時0毫秒后給我一個消息”。定時器線程收到消息，發(fā)現(xiàn)只要等待0毫秒，立馬就給Main Thread一個消息，“我這邊已經(jīng)過了0毫秒了”。Main Thread收到這個回復(fù)消息后，就把相應(yīng)宏任務(wù)的狀態(tài)置為runnable，這個宏任務(wù)就可以被Event Loop撈起了。

可以看到，經(jīng)過這樣一個線程間通信的過程，即便是延時0毫秒的定時器，其回調(diào)也并不是在真正意義上的0毫秒之后執(zhí)行，因為通信過程就需要耗費時間。網(wǎng)上有個觀點說setTimeout 0的響應(yīng)時間最少是4ms，其實也是有依據(jù)的，不過也是有條件的。

HTML Living Standard: If nesting level is greater than 5, and timeout is less than 4, then set timeout to 4.

對于這種說法，我覺得自己有個概念就行，不同瀏覽器在實現(xiàn)規(guī)范的細(xì)節(jié)上肯定不一樣，具體通信過程也不詳，是不是4ms也不好說，關(guān)鍵是你有沒有搞清楚這背后經(jīng)歷了什么。

微任務(wù)進(jìn)隊列

前面我們提到一個觀點，執(zhí)行完一個Task后，如果Microtask隊列不為空，會把Microtask隊列中所有的Microtask都取出來執(zhí)行。我認(rèn)為，Microtask不是在注冊時就進(jìn)入Microtask隊列，因為Event Loop處理Microtask隊列時，并不會判斷Microtask的狀態(tài)。反過來想，如果Microtask在注冊時就進(jìn)入Microtask隊列，就會存在Microtask還未變?yōu)閞unnable狀態(tài)就被執(zhí)行的情況，這顯然是不合理的。我的觀點是，Microtask在變?yōu)閞unnable狀態(tài)時才進(jìn)入Microtask隊列。

那么我們來分析下Microtask什么時候變成runnable狀態(tài)，首先來看看Promise。

var promise1 = new Promise((resolve, reject) => { 
    resolve(1); 
}) 
promise1.then(res => { 
    console.log('promise1微任務(wù)被執(zhí)行了') 
}) 

讀者們，我的第一個問題是，Promise的微任務(wù)什么時候被注冊?new Promise的時候?還是什么時候?不妨來猜一猜!

答案是.then被執(zhí)行的時候。(當(dāng)然，還有.catch的情況，這里只是就這個例子說)。

那么Promise微任務(wù)的狀態(tài)什么時候變成runnable呢?相信不少讀者已經(jīng)有了頭緒了，沒錯，就是Promise狀態(tài)發(fā)生轉(zhuǎn)移的時候，在本例中也就是resolve(1)被執(zhí)行的時候，Promise狀態(tài)由pending轉(zhuǎn)移為fulfilled。在resolve(1)執(zhí)行后，這個Promise微任務(wù)就進(jìn)入Microtask隊列了，并且將在本次Event Loop中被執(zhí)行。

基于這個例子，我們再來加深下難度。

var promise1 = new Promise((resolve, reject) => { 
    setTimeout(() => { 
        resolve(1); 
    }, 0); 
}); 
promise1.then(res => { 
    console.log('promise1微任務(wù)被執(zhí)行了'); 
}); 

在這個例子中，Promise微任務(wù)的注冊和進(jìn)隊列并不在同一次Event Loop。怎么說呢?在第一個Event Loop中，通過.then注冊了微任務(wù)，但是我們可以發(fā)現(xiàn)，new Promise時，執(zhí)行了一個setTimeout，這是相當(dāng)于注冊了一個宏任務(wù)。而resolve(1)必須在宏任務(wù)被執(zhí)行時才會執(zhí)行。很明顯，兩者中間隔了至少一次Event Loop。

如果能分析Promise微任務(wù)的過程，你自然就知道怎么分析ObserverMutation微任務(wù)的過程了，這里不再贅述。

如果Microtask執(zhí)行時又創(chuàng)建了Microtask，怎么處理?

我們知道，一次Event Loop最多只執(zhí)行一個runnable的Task，但是會執(zhí)行Microtask隊列中的所有Microtask。如果在執(zhí)行Microtask時，又創(chuàng)建了新的Microtask，這個新的Microtask是在下次Event Loop中被執(zhí)行嗎?答案是否定的。微任務(wù)可以添加新的微任務(wù)到隊列中，并在下一個任務(wù)開始執(zhí)行之前且當(dāng)前Event Loop結(jié)束之前執(zhí)行完所有的微任務(wù)。請注意不要遞歸地創(chuàng)建微任務(wù)，否則會陷入死循環(huán)。

下面就是一個糟糕的示例。

// bad case 
function recursionMicrotask() { 
 Promise.resolve().then(() => { 
  recursionMicrotask() 
 }) 
} 
recursionMicrotask(); 

請不要輕易嘗試，否則頁面會卡死哦!(因為Microtask占著Main Thread不釋放，瀏覽器渲染都沒辦法進(jìn)行了)

為什么要區(qū)分Task和Microtask?

這是一個非常重要的問題。為什么不在執(zhí)行完Task后，直接進(jìn)行瀏覽器渲染這一步驟，而要再加上執(zhí)行Microtask這一步呢?其實在前面的問題中已經(jīng)解答過了。一次Event Loop只會消費一個宏任務(wù)，而微任務(wù)隊列在被消費時有“繼續(xù)上車”的機(jī)制，這就讓開發(fā)者有了更多的想象力，對代碼的控制力會更強(qiáng)。

做幾道題熱熱身?

在沖擊Promise/A+規(guī)范前，不妨先用幾個習(xí)題來測試下自己對Promise的理解程度。

基本操作

function mutationCallback(mutationRecords, observer) { 
    console.log('mt1') 
} 
 
const observer = new MutationObserver(mutationCallback) 
observer.observe(document.body, { attributes: true }) 
 
Promise.resolve().then(() => { 
    console.log('mt2') 
    setTimeout(() => { 
        console.log('t1') 
    }, 0) 
    document.body.setAttribute('test', "a") 
}).then(() => { 
    console.log('mt3') 
}) 
 
setTimeout(() => { 
    console.log('t2') 
}, 0) 

這道題就不分析了，答案：mt2 mt1 mt3 t2 t1

瀏覽器不講武德?

Promise.resolve().then(() => { 
    console.log(0); 
    return Promise.resolve(4); 
}).then((res) => { 
    console.log(res) 
}) 
 
Promise.resolve().then(() => { 
    console.log(1); 
}).then(() => { 
    console.log(2); 
}).then(() => { 
    console.log(3); 
}).then(() => { 
    console.log(5); 
}).then(() =>{ 
    console.log(6); 
}) 

這道題據(jù)說是字節(jié)內(nèi)部流出的一道題，說實話我剛看到的時候也是一頭霧水。經(jīng)過我在Chrome測試，得到的答案確實很有規(guī)律，就是：0 1 2 3 4 5 6。

先輸出0，再輸出1，我還能理解，為什么輸出2和3后又突然跳到4呢，瀏覽器你不講武德啊!

emm...我被戴上了痛苦面具!

那么這背后的執(zhí)行順序到底是怎樣的呢?仔細(xì)分析下，你會發(fā)現(xiàn)還是有跡可循的。

老規(guī)矩，第一個問題，這道題的代碼執(zhí)行過程中，產(chǎn)生了多少個微任務(wù)?可能很多人認(rèn)為是7個，但實際上應(yīng)該是8個。

• 同步任務(wù)執(zhí)行，注冊mt1~mt7七個微任務(wù)，此時execution context stack為空，并且mt1和mt3的狀態(tài)變?yōu)閞unnable。JS引擎安排mt1和mt3進(jìn)入Microtask隊列(通過HostEnqueuePromiseJob實現(xiàn))。
• Perform a microtask checkpoint，由于mt1和mt3是在同一次JS call中變?yōu)閞unnable的，所以mt1和mt3的回調(diào)先后進(jìn)入execution context stack執(zhí)行。
• mt1回調(diào)進(jìn)入execution context stack執(zhí)行，輸出0，返回Promise.resolve(4)。mt1出隊列。由于mt1回調(diào)返回的是一個狀態(tài)為fulfilled的Promise，所以之后JS引擎會安排一個job(job是ecma中的概念，等同于微任務(wù)的概念，這里先給它編號mt8)，其回調(diào)目的是讓mt2的狀態(tài)變?yōu)閒ulfilled(前提是當(dāng)前execution context stack is empty)。所以緊接著還是先執(zhí)行mt3的回調(diào)。
• mt3回調(diào)進(jìn)入execution context stack執(zhí)行，輸出1，mt4變?yōu)閞unnable狀態(tài)，execution context stack is empty，mt3出隊列。
• 由于此時mt4已經(jīng)是runnable狀態(tài)，JS引擎安排mt4進(jìn)隊列，接著JS引擎會安排mt8進(jìn)隊列。
• 接著，mt4回調(diào)進(jìn)入execution context stack執(zhí)行，輸出2，mt5變?yōu)閞unnable，mt4出隊列。JS引擎安排mt5進(jìn)入Microtask隊列。
• mt8回調(diào)執(zhí)行，目的是讓mt2變成runnable狀態(tài)，mt8出隊列。mt2進(jìn)隊列。
• mt5回調(diào)執(zhí)行，輸出3，mt6變?yōu)閞unnable，mt5出隊列。mt6進(jìn)隊列。
• mt2回調(diào)執(zhí)行，輸出4，mt4出隊列。
• mt6回調(diào)執(zhí)行，輸出5，mt7變?yōu)閞unnable，mt6出隊列。mt7進(jìn)隊列。
• mt7回調(diào)執(zhí)行，輸出6，mt7出隊列。執(zhí)行完畢!總體來看，輸出結(jié)果依次為：0 1 2 3 4 5 6。

對這塊執(zhí)行過程尚有疑問的朋友，可以先往下看看Promise/A+規(guī)范和ECMAScript262規(guī)范中關(guān)于Promise的約定，再回過頭來思考，也歡迎留言與我交流!

經(jīng)過我在Edge瀏覽器測試，結(jié)果是：0 1 2 4 3 5 6?？梢钥吹剑煌瑸g覽器在實現(xiàn)Promise的主流程上是吻合的，但是在一些細(xì)枝末節(jié)上還有不一致的地方。實際應(yīng)用中，我們只要注意規(guī)避這種問題即可。

實現(xiàn)Promise/A+

熱身完畢，接下來就是直面大boss Promise/A+規(guī)范[6]。Promise/A+規(guī)范列舉了大大小小三十余條細(xì)則，一眼看過去還是挺暈的。

仔細(xì)閱讀多遍規(guī)范之后，我有了一個基本認(rèn)識，要實現(xiàn)Promise/A+規(guī)范，關(guān)鍵是要理清其中幾個核心點。

關(guān)系鏈路

本來寫了大幾千字有點覺得疲倦了，于是想著最后這部分就用文字講解快速收尾，但是最后這節(jié)寫到一半時，我覺得我寫不下去了，純文字的東西太干了，干得沒法吸收，這對那些對Promise掌握程度不夠的讀者來說是相當(dāng)不友好的。所以，我覺得還是先用一張圖來描述一下Promise的關(guān)系鏈路。

首先，Promise它是一個對象，而Promise/A+規(guī)范則是圍繞著Promise的原型方法.then()展開的。

• .then()的特殊性在于，它會返回一個新的Promise實例，在這種連續(xù)調(diào)用.then()的情況下，就會串起一個Promise鏈，這與原型鏈又有一些相似之處。“恬不知恥”地再推薦一篇「思維導(dǎo)圖學(xué)前端 」6k字一文搞懂Javascript對象，原型，繼承[7]，哈哈哈。
• 另一個靈活的地方在于，p1.then(onFulfilled, onRejected)返回的新Promise實例p2，其狀態(tài)轉(zhuǎn)移的發(fā)生是在p1的狀態(tài)轉(zhuǎn)移發(fā)生之后(這里的之后指的是異步的之后)。并且，p2的狀態(tài)轉(zhuǎn)移為Fulfilled還是Rejected，這一點取決于onFulfilled或onRejected的返回值，這里有一個較為復(fù)雜的分析過程，也就是后面所述的Promise Resolution Procedure算法。

我這里畫了一個簡單的時序圖，畫圖水平很差，只是為了讓讀者們先有個基本印象。

其中還有很多細(xì)節(jié)是沒提到的(因為細(xì)節(jié)真的太多了，全部畫出來就相當(dāng)復(fù)雜，具體過程請看我文末附的源碼)。

nextTick

看了前面內(nèi)容，相信大家都有一個概念，微任務(wù)是一個異步任務(wù)，而我們要實現(xiàn)Promise的整套異步機(jī)制，必然要具備模擬微任務(wù)異步回調(diào)的能力。在規(guī)范中也提到了這么一條信息：

This can be implemented with either a “macro-task” mechanism such as setTimeout or setImmediate, or with a “micro-task” mechanism such as MutationObserver or process.nextTick.

我這里選擇的是用微任務(wù)來實現(xiàn)異步回調(diào)，如果用宏任務(wù)來實現(xiàn)異步回調(diào)，那么在Promise微任務(wù)隊列執(zhí)行過程中就可能會穿插宏任務(wù)，這就不太符合微任務(wù)隊列的調(diào)度邏輯了。這里還對Node環(huán)境和瀏覽器環(huán)境做了兼容，Node環(huán)境中可以使用process.nextTick回調(diào)來模擬微任務(wù)的執(zhí)行，而在瀏覽器環(huán)境中我們可以選擇MutationObserver。

function nextTick(callback) { 
  if (typeof process !== 'undefined' && typeof process.nextTick === 'function') { 
    process.nextTick(callback) 
  } else { 
    const observer = new MutationObserver(callback) 
    const textNode = document.createTextNode('1') 
    observer.observe(textNode, { 
      characterData: true 
    }) 
    textNode.data = '2' 
  } 
} 

狀態(tài)轉(zhuǎn)移

Promise實例一共有三種狀態(tài)，分別是Pending, Fulfilled, Rejected，初始狀態(tài)是Pending。

const PROMISE_STATES = { 
  PENDING: 'pending', 
  FULFILLED: 'fulfilled', 
  REJECTED: 'rejected' 
} 
 
class MyPromise { 
  constructor(executor) { 
    this.state = PROMISE_STATES.PENDING; 
  } 
  // ...其他代碼 
} 

一旦Promise的狀態(tài)發(fā)生轉(zhuǎn)移，就不可再轉(zhuǎn)移為其他狀態(tài)。

/** 
 * 封裝Promise狀態(tài)轉(zhuǎn)移的過程 
 * @param {MyPromise} promise 發(fā)生狀態(tài)轉(zhuǎn)移的Promise實例 
 * @param {*} targetState 目標(biāo)狀態(tài) 
 * @param {*} value 伴隨狀態(tài)轉(zhuǎn)移的值，可能是fulfilled的值，也可能是rejected的原因 
 */ 
function transition(promise, targetState, value) { 
  if (promise.state === PROMISE_STATES.PENDING && targetState !== PROMISE_STATES.PENDING) { 
    // 2.1: state只能由pending轉(zhuǎn)為其他態(tài)，狀態(tài)轉(zhuǎn)移后，state和value的值不再變化 
    Object.defineProperty(promise, 'state', { 
      configurable: false, 
      writable: false, 
      enumerable: true, 
      value: targetState 
    }) 
    // ...其他代碼 
  } 
} 

觸發(fā)狀態(tài)轉(zhuǎn)移是靠調(diào)用resolve()或reject()實現(xiàn)的。當(dāng)resolve()被調(diào)用時，當(dāng)前Promise也不一定會立即變?yōu)镕ulfilled狀態(tài)，因為傳入resolve(value)方法的value有可能也是一個Promise，這個時候，當(dāng)前Promise必須追蹤傳入的這個Promise的狀態(tài)，整個確定Promise狀態(tài)的過程是通過Promise Resolution Procedure算法實現(xiàn)的，具體細(xì)節(jié)封裝到了下面代碼中的resolvePromiseWithValue函數(shù)中。當(dāng)reject()被調(diào)用時，當(dāng)前Promise的狀態(tài)就是確定的，一定是Rejected，此時可以通過transition函數(shù)(封裝了狀態(tài)轉(zhuǎn)移的細(xì)節(jié))將Promise的狀態(tài)進(jìn)行轉(zhuǎn)移，并執(zhí)行后續(xù)動作。

// resolve的執(zhí)行，是一個觸發(fā)信號，基于此進(jìn)行下一步的操作 
function resolve(value) { 
  resolvePromiseWithValue(this, value) 
} 
// reject的執(zhí)行，是狀態(tài)可以變?yōu)镽ejected的信號 
function reject(reason) { 
  transition(this, PROMISE_STATES.REJECTED, reason) 
} 
 
class MyPromise { 
  constructor(executor) { 
    this.state = PROMISE_STATES.PENDING; 
    this.fulfillQueue = []; 
    this.rejectQueue = []; 
    // 構(gòu)造Promise實例后，立刻調(diào)用executor 
    executor(resolve.bind(this), reject.bind(this)) 
  } 
} 

鏈?zhǔn)阶粉?/strong>

// 回調(diào)應(yīng)異步執(zhí)行，所以用到了nextTick 
nextTick(() => { 
  // then可能會被調(diào)用多次，所以異步回調(diào)應(yīng)該用數(shù)組來維護(hù) 
  promise.fulfillQueue.forEach(({ handler, chainedPromise }) => { 
    try { 
      if (typeof handler === 'function') { 
        const adoptedValue = handler(value) 
        // 異步回調(diào)返回的值將決定衍生的Promise的狀態(tài) 
        resolvePromiseWithValue(chainedPromise, adoptedValue) 
      } else { 
        // 存在調(diào)用了then，但是沒傳回調(diào)作為參數(shù)的可能，此時衍生的Promise的狀態(tài)直接采納其關(guān)聯(lián)的Promise的狀態(tài)。 
        transition(chainedPromise, PROMISE_STATES.FULFILLED, promise.value) 
      } 
    } catch (error) { 
      // 如果回調(diào)拋出了異常，此時直接將衍生的Promise的狀態(tài)轉(zhuǎn)移為rejected，并用異常error作為reason 
      transition(chainedPromise, PROMISE_STATES.REJECTED, error) 
    } 
  }) 
  // 最后清空該P(yáng)romise關(guān)聯(lián)的回調(diào)隊列 
  promise.fulfillQueue = []; 
}） 

if (promise === x) { 
    // 2.3.1 由于Promise采納狀態(tài)的機(jī)制，這里必須進(jìn)行全等判斷，防止出現(xiàn)死循環(huán) 
    transition(promise, PROMISE_STATES.REJECTED, new TypeError('promise and x cannot refer to a same object.')) 
} 

2.3.2 If x is a promise, adopt its state [3.4]: 
2.3.2.1 If x is pending, promise must remain pending until x is fulfilled or rejected. 
2.3.2.2 If/when x is fulfilled, fulfill promise with the same value. 
2.3.2.3 If/when x is rejected, reject promise with the same reason. 

else if (isPromise(x)) { 
    // 2.3.2 如果x是一個Promise實例，則追蹤并采納其狀態(tài) 
    if (x.state !== PROMISE_STATES.PENDING) { 
      // 假設(shè)x的狀態(tài)已經(jīng)發(fā)生轉(zhuǎn)移，則直接采納其狀態(tài) 
      transition(promise, x.state, x.state === PROMISE_STATES.FULFILLED ? x.value : x.reason) 
    } else { 
      // 假設(shè)x的狀態(tài)還是pending，則只需等待x狀態(tài)確定后再進(jìn)行promise的狀態(tài)轉(zhuǎn)移 
      // 而x的狀態(tài)轉(zhuǎn)移結(jié)果是不定的，所以兩種情況我們都需要進(jìn)行訂閱 
      // 這里用一個.then很巧妙地完成了訂閱動作 
      x.then(value => { 
        // x狀態(tài)轉(zhuǎn)移為fulfilled，由于callback傳過來的value是不確定的類型，所以需要繼續(xù)應(yīng)用Promise Resolution Procedure算法 
        resolvePromiseWithValue(promise, value, thenableValues) 
      }, reason => { 
        // x狀態(tài)轉(zhuǎn)移為rejected 
        transition(promise, PROMISE_STATES.REJECTED, reason) 
      }) 
    } 
}