node.js的documentation描述了其基礎事件循環的所謂的階段。
它明確指出空閒和準備階段是只在內部使用。Node.js：爲什麼閒置和準備階段僅在內部使用？
對於node.js的事件循環是libuv之一，不言而喻，這些階段可能映射到libuv的idle和prepare句柄上。
它們將有助於在組織軟件中的任務時擁有更大的粒度。特別是，它們是執行I/O回調和投票階段之間的唯一方式。
無論如何，他們不是從底層環境出口。
這些階段被禁止的原因是什麼，實際上給用戶一個比libuv提供的事件循環顯然最差的事件循環？
有沒有其他的方式來按上述方式安排任務？
注意：這只是好奇心。
我曾經與libuv和nodejs一起工作，我注意到了它，所以我想知道是否有技術上的原因或...呃，這是它的設計方式，沒有特別的理由。
我不認爲有一個具體的理由來「禁止」他們。而且，他們不是真的被禁止，他們只是沒有暴露。你可以創建一個Node插件，它允許你創建空閒和準備句柄，並且完全沒有問題。有一些事情你必須知道的：
空閒手柄有一個可怕的名字：當循環實際上是空閒的，它們不運行。它們在循環迭代中運行一次，在定時器之後運行，並且如果任何空閒計時器處於活動狀態，則循環將在零秒內阻塞I/O。所以它們可能很危險，因爲如果不停止它，CPU會旋轉。 > JS邊界交叉（參見至MakeCallback呼叫），從而I/O回調可以推遲並稍後運行位 - 與process.nextTick註冊
回調的C++ <時被調用。如果你向JS公開了準備句柄，你會在C++代碼中使用MakeCallback，所以process.nextTick回調函數中的一些也會在你準備好的回調函數中被調用。
作爲一般說明：閒置，檢查和準備句柄從某種程度上繼承自libev（libuv在內部使用）。如上所述，在將libuv與其他庫進行嵌入時，可以使用檢查和準備，並且空閒句柄有些奇怪。而且，libuv現在也走自己的路，所以不是所有的libuv都會暴露在Node中。
你可以問一個相反的問題：「爲什麼你需要空閒階段，例如，被暴露」？您可以使用setImmediate()。
此外，爲什麼你要在I/O回調和輪詢階段之間執行一些操作，因爲你無法明確控制這些事情呢？