看到過下面這樣一道題：

(function test() {
    setTimeout(function() {console.log(4)}, 0);
    new Promise(function executor(resolve) {
        console.log(1);
        for( var i=0 ; i<10000 ; i++ ) {
            i == 9999 && resolve();
        }
        console.log(2);
    }).then(function() {
        console.log(5);
    });
    console.log(3);
})()複製程式碼

為什麼輸出結果是 1,2,3,5,4 而非 1,2,3,4,5 ？

比較難回答，但我們可以首先說一說可以從輸出結果反推出的結論：

1. Promise.then 是非同步執行的，而建立Promise例項（ executor ）是同步執行的。
2. setTimeout 的非同步和 Promise.then 的非同步看起來 “不太一樣” ——至少是不在同一個佇列中。

相關規範摘錄

在解答問題前，我們必須先去了解相關的知識。(這部分相當枯燥，想看結論的同學可以跳到最後即可。)

Promise/A+ 規範

要想找到原因，最自然的做法就是去看規範。我們首先去看看 Promise的規範 。

摘錄 promise.then 相關的部分如下：

規範要求， onFulfilled 必須在 執行上下文棧（execution context stack） 只包含 平臺程式碼（platform code） 後才能執行。平臺程式碼指 引擎，環境，Promise實現程式碼。實踐上來說，這個要求保證了 onFulfilled 的非同步執行（以全新的棧），在 then 被呼叫的這個事件迴圈之後。

規範的實現可以通過 macro-task 機制，比如 setTimeout 和 setImmediate ，或者 micro-task 機制，比如 MutationObserver 或者 process.nextTick 。因為promise的實現被認為是平臺程式碼，所以可以自己包涵一個 task-scheduling 佇列或者 trampoline 。

通過對規範的翻譯和解讀，我們可以確定的是 promise.then 是非同步的，但它的實現又是平臺相關的。要繼續解答我們的疑問，必須理解下面幾個概念：

1. Event Loop，應該算是一個前置的概念，理解它才能理解瀏覽器的非同步工作流程。
2. macro-task 機制和 micro-task 機制，這組概念很新，之前根本沒聽過，但卻是解決問題的核心。

Event Loop 規範

HTML5 規範裡有 Event loops 這一章節（讀起來比較晦澀，只關注相關部分即可）。

1. 每個瀏覽器環境，至多有一個event loop。
2. 一個event loop可以有1個或多個task queue。
3. 一個task queue是一列有序的task，用來做以下工作： Events task， Parsing task， Callbacks task， Using a resource task， Reacting to DOM manipulation task等。

每個task都有自己相關的document，比如一個task在某個element的上下文中進入佇列，那麼它的document就是這個element的document。

每個task定義時都有一個task source，從同一個task source來的task必須放到同一個task queue，從不同源來的則被新增到不同佇列。

每個(task source對應的)task queue都保證自己佇列的先進先出的執行順序，但event loop的每個turn，是由瀏覽器決定從哪個task source挑選task。這允許瀏覽器為不同的task source設定不同的優先順序，比如為使用者互動設定更高優先順序來使使用者感覺流暢。

Jobs and Job Queues 規範

本來應該接著上面Event Loop的話題繼續深入，講macro-task和micro-task，但先不急，我們跳到 ES2015 規範，看看 Jobs and Job Queues 這一新增的概念，它有點類似於上面提到的 task queue 。

一個 Job Queue 是一個先進先出的佇列。一個ECMAScript實現必須至少包含以下兩個 Job Queue ：

單個 Job Queue 中的PendingJob總是按序（先進先出）執行，但多個 Job Queue 可能會交錯執行。

跟隨PromiseJobs到25.4章節，可以看到 PerformPromiseThen ( promise, onFulfilled, onRejected, resultCapability ) ：

這裡我們看到， promise.then 的執行其實是向 PromiseJobs 新增Job。

event loop怎麼處理tasks和microtasks?

好了，現在可以讓我們真正來深入task（macro-task）和micro-task。

認真說，規範並沒有包括macro-task 和 micro-task這部分概念的描述，但閱讀一些大神的博文以及從規範相關概念推測，以下所提到的在我看來，是合理的解釋。但是請看文章的同學辯證和批判地看。

首先， micro-task在ES2015規範中稱為Job。 其次，macro-task代指task。

哇，所以我們可以結合前面的規範，來講一講Event Loop（事件迴圈）是怎麼來處理task和microtask的了。

1. 每個執行緒有自己的事件迴圈，所以每個web worker有自己的，所以它才可以獨立執行。然而，所有同屬一個origin的windows共享一個事件迴圈，所以它們可以同步交流。
2. 事件迴圈不間斷在跑，執行任何進入佇列的task。
3. 一個事件迴圈可以有多個task source，每個task source保證自己的任務列表的執行順序，但由瀏覽器在（事件迴圈的）每輪中挑選某個task source的task。
4. tasks are scheduled，所以瀏覽器可以從內部到JS/DOM，保證動作按序發生。在tasks之間，瀏覽器可能會render updates。從滑鼠點選到事件回撥需要schedule task，解析html，setTimeout這些都需要。
5. microtasks are scheduled，經常是為需要直接在當前指令碼執行完後立即發生的事，比如async某些動作但不必承擔新開task的弊端。microtask queue在回撥之後執行，只要沒有其它JS在執行中，並且在每個task的結尾。microtask中新增的microtask也被新增到microtask queue的末尾並處理。microtask包括 mutation observer callbacks 和 promise callbacks 。

結論

定位到開頭的題目，流程如下：

1. 當前task執行，執行程式碼。首先 setTimeout 的callback被新增到tasks queue中；
2. 例項化promise，輸出 1 ; promise resolved；輸出 2 ;
3. promise.then 的callback被新增到microtasks queue中；
4. 輸出 3 ;
5. 已到當前task的end，執行microtasks，輸出 5 ;
6. 執行下一個task，輸出 4 。