在這一節中，我們將通過解釋Windows下異步I/O（利用IOCP實現）的簡單例子來探尋從JavaScript代碼到系統內核之間都發生了什么。 對于一般的（非異步）回調函數，函數由我們自行調用，如下所示： ~~~ var forEach = function(list, callback){ for(var i=0;i<list.length;i++){ callback(list[i],i,list); } }; ~~~ 對于Node中的異步I/O調用而言，回調函數卻不由開發者來調用。那么從我們發出調用后，到回調函數被執行，中間發生了什么呢？事實上，從JavaScript發起調用到內核執行完I/O操作的過渡過程中，存在一種中間產物，它叫做請求對象。 下面我們以最簡單的fs.open()方法來作例子，探索Node與底層之間是如何執行異步I/O調用以及回調函數究竟是如何被調用執行的： ~~~ fs.open=function(path, flags, mode, callback){ //... binding.open(pathModule._makeLong(path), stringToFlags(flags), mode, callback); }; ~~~ fs.open()的作用是根據指定路徑和參數去打開一個文件，從而得到一個文件描述符，這是后續所有I/O操作的初始操作。從前面的代碼中可以看到，JavaScript層面的代碼通過調用C++核心模塊進行下層的操作。下圖為調用示意圖：  從JavaScript調用Node的核心模塊，核心模塊調用C++內建模塊，內建模塊通過libuv進行系統調用，這是Node里經典的調用方式。這里libuv作為封裝層，有兩個平臺實現，實質上是調用了uv_fs_open()方法。在uv_fs_open()的調用過程中，我們創建了一個FSReqWrap請求對象。從JavaScript層傳入的參數和當前方法都被封裝在這個請求對象中，其中我們最為關注的回調函數則被設置在這個對象的oncomplete_sym屬性上： ~~~ req_wrap->object->Set(oncomplete_sym, callback); ~~~ 對象包裝完畢后，在Windows下，則調用QueueUserWorkItem()方法將這個FSReqWrap對象推入線程池中等待執行，該方法的代碼如下所示： ~~~ QueueUserWorkItem(&uv_fs_thread_proc, \ req, \ WT_EXECUTEDEFAULT) ~~~ QueueUserWorkItem()方法接受3個參數：第一個參數是將要執行的方法的引用，這里引用的是uv_fs_thread_proc，第二個參數是uv_fs_thread_proc方法運行時所需要的參數；第三個參數是執行的標志。當線程池中有可用線程時，我們會調用uv_fs_thread_proc()方法。uv_fs_thread_proc()方法會根據傳入的參數的類型調用相應的底層函數。以uv_fs_open()為例，實際上調用fs_open()方法。 至此，JavaScript調用立即返回，由JavaScript層面發起的異步調用的第一階段就此結束。JavaScript線程可以繼續執行當前任務的后續操作。當前的I/O操作在線程池中等待執行，不管它是否阻塞I/O，都不會影響到JavaScript線程的后續執行，如此就達到了異步的目的。 請求對象是異步I/O過程中的重要中間產物，所有的狀態都保存在這個對象中，包括送入線程池等待執行以及I/O操作完畢后的回調處理。