在前一篇的我只是個物流中心調度員——解構 Node.js Event Loop 的六大停靠站中，我們見識到了前台調度專員如何透過遵循工作指引（Event Loop）循環繞行六大站點，按部就班地完成「黑鼠宅急便」海量的物流訂單。然而，若想成為一位優秀的前台調度專員，不能只靠循規蹈矩的巡邏。
除了最基本的「收單」（I/O Event）與「派單」（Register / Schedule），專員真正的考驗在於：如何在永無止盡的循環路徑中，精準地安插那些突如其來的急件單據？這正是微任務（Microtasks）所要解決的問題。此外，當物流中心面對驚人數量的訂單時，前台調度專員還必須思考兩件事：應該選擇擴編搬運工班以維持吞吐量，或者應該成立獨立的「專案辦公室」來分攤這些超量訂單？
本次我們將深入探討前台調度專員口袋裡的微任務（Microtasks）優先級，以及在極限高併發場景下，資深專員如何透過調度搬運工團隊（Thread Pool）與成立專案辦公室（Worker Threads），來將物流效率推向另一個巔峰。
一、 前台調度專員的強迫症：完成大任務後，馬上做小任務
除了循環繞行六大站點之外，前台調度專員口袋裡還有一個急件專用呼叫器，每當執行完任何一個宏任務（Macrotask），例如收單、派單、檢查計時器、領取搬運工的單據等，並必須馬上執行急件專用呼叫器上顯示的微任務（Microtasks），這是 Node.js 執行順序中最重要的「插隊規則」。
- 清空機制 (Microtask Checkpoint)： 在 Node.js 11+ 版本後，調度專員的強迫症變得更為「強迫」。他不需要巡視完整個站點，而是每當處理完「任何一個」宏任務（Macrotask），就會立刻停下手邊動作，檢查急件專用呼叫器上是否有微任務（Microtasks）需要執行。
- 優先順序（The Priority Chain)： 急件專用呼叫器的「任務緊急程度」是規定好的：
- 紅色標籤（process.nextTick）：這是 Node.js 內部的最速通道。專員會先優先執行具有紅色標籤的緊急任務。
- 藍色標籤（Promise.then）：在確認呼叫器上沒有紅標籤的任務後，才會開始處理藍色標籤的緊急任務。
小提醒：只要專員還在處理呼叫器上的任務，他就不會移動到下一個站點或領取單據。因此，微任務可以精確地攔截宏任務之間的空隙。
二、 插隊的藝術： 為什麼 setImmediate 總是在 setTimeout 之後？
在 Node.js 的物流體系中，任務的執行順序並非隨機，其受限於調度專員在物流中心內的「單向行進路徑」。任務被分派到哪個站點，以及專員當下所處的位置（出發點），共同決定了哪個任務會被先處理。
- 路徑分析：當我們在用於讀取檔案的
fs.readFile的回呼函式（Callback）中同時寫下setImmediate和setTimeout兩者，會觸發以下調度邏輯： - 場景：專員目前正站在 站點 4：進貨感應區 (Poll) 處理搬運工提交的完成單據。
- 派單：專員同時執行了兩次派單，新增了一張
setTimeout（在 站點 1（預約包裹區）執行）和一張setImmediate（在 站點 5（快捷窗口）執行）。 - 移動：在離開 站點 4（進貨感應區）後，根據指引規定的下一站是 站點 5（快捷窗口）。
- 結果：專員會先在 站點 5（快捷窗口）看到
setImmediate並執行它；而setTimeout必須等專員繞完一整圈，回到下一輪的 站點 1（預約包裹區）才會被執行。
與微任務（Microtasks）的關聯： 雖然 setImmediate 在路徑上具備優勢，會在站點 5 被優先執行，但它仍是一個宏任務（Macrotask）。 這表示：每當專員在 站點 4 處理完一個宏任務（Macrotask）後，他不會馬上移動到 站點 5，而是會先清空急件專用呼叫器裡所有的微任務（如紅色標籤 nextTick 或藍色標籤 Promise），接著才會移動到站點 5 來處理 setImmediate 單據。
任務的緊急程度：急件專用呼叫器 (Microtasks) > 物理路徑上的下一站 (setImmediate) > 重新繞回起點 (setTimeout)。
三、 預防勝於治療：當重大災難發生時該如何應對
依靠唯一一位前台調度專員（Main Thread）引導整座物流中心的運作，是 Node.js 能夠以極低資源達成高效能的精髓；然而，這種架構也存在著「一則以喜，一則以優」的風險。一旦這位專員因故動彈不得，整個物流體系便會陷入停滯。理解系統如何崩潰，並且提前預防，正是資深專員的價值所在。
- 前台調度專員被綁架 (Blocking Main Thread)： 如果專員被迫執行一個極度耗時的任務，例如耗時 10 秒的加密計算（如
pbkdf2Sync），他會被困在原地處理這個任務，無法根據工作指引來巡邏物流中心。此時： - 感應門嗶嗶叫：沒有人能去感應門（epoll / kqueue）領取單據，導致新的網路請求進不來（TCP 隊列滿載），發生阻塞。
- 預約逾時：明明預約時間到了，卻沒人去站點 1（預約包裹區）執行到期的單據。
- 事件循環飢餓 (Event Loop Starvation)： 這是比阻塞更可怕的災難。由於專員在宏任務結束後，必須完全清空所有微任務，在
process.nextTick裡又呼叫了process.nextTick（遞迴）的情況下，新插入的 nextTick 會在當前清空迴圈中繼續被執行，導致隊列永遠無法被「清空」，因此專員會陷入「永無止盡的緊急任務循環」。與被綁架不同的是，被綁架時系統至少是靜止的；在飢餓發生時系統看似忙碌，卻完全沒有實際產出，這讓問題更難被察覺與排除。
現象：CPU 的負載飆高，但物流中心（Event Loop）卻完全停止運轉，沒有任務被完成，這是因為專員被困在原地執行手上的任務，沒有機會邁開步伐去巡視物流中心。
四、 資深專員的調度優化：擴編工班與成立「專案辦公室」
當物流中心訂單量大到鼴鼠員工們每天加班也做不完時，只叫搬運工們搬快一點是沒有用的，身為一個專業的鼴鼠專員，必須從架構層面進行「人力資源調度」。
- 擴編後勤工班 (UV_THREADPOOL_SIZE)： 預設只有 4 位搬運工。如果同時下達了 10 個大型檔案讀取請求，第 5 個檔案會卡在排隊區。透過環境變數
UV_THREADPOOL_SIZE，可以調整工班人數（最高 128），當系統遭遇大量的檔案存取、DNS 查詢或非硬體加速的加密任務時，適度擴編能顯著地提升物流中心的吞吐量。 - 成立「專案辦公室」（Worker Threads）：有些任務不僅耗體力，還極度「燒腦」——例如大數據運算、圖像處理或繁重的 JSON 解析。這些任務若交給後勤搬運工（Thread Pool），他們可能力有未逮；若交給前台調度專員（Main Thread），則會導致物流中心癱瘓。
- 此時，最明智的作法是動用
Worker Threads，在物流中心旁搭建出一間獨立的「專案辦公室」。這間辦公室擁有獨立的前台調度專員、獨立的工作指引（Event Loop）。值得一提的是，專案辦公室與物流中心本身共用同一個後勤搬運工團隊（Thread Pool），這表示當有多間專案辦公室同時運作、又各別發出大量 I/O 請求時，所有人都在競用同一批搬運工人力——這也是為何前述「擴編工班人數」如此重要。 - 回報成果：待專案辦公室獨立地完成這個複雜又燒腦的任務後，會透過「內部通訊機制（PostMessage）」將結果送回物流中心。物流中心的專員會在下一輪巡視時於 站點 4（Poll Phase）領取這張成果單據並執行收尾工作。
- 此時，最明智的作法是動用
Worker Threads 與 Main Thread 的關係
五、 結語：微任務——調度專員口袋裡的緊急呼叫器
在 Node.js 的調度體系中，前台調度專員口袋裡始終有一個緊急任務呼叫器，呼叫器上的微任務（Microtasks）並非用來處理沉重的貨物，其設計初衷是作為一套「極速修補與狀態同步」的機制。微任務最大功能是，確保開發者能夠在「下一個宏任務（Macrotask）開始前」，獲得一個絕對優先的執行空檔，用以確保資料的一致性與即時的邏輯回饋。
