IOCP以其高效的性能受到服務器開發者的青睞，本人有幸在當前的項目中使用了該異步模型，修改調試之余，總結出開發過程中的經驗若干，供大家借鑒。
首先是需要注意的是OVERLAPPED結構。想必該結構大多數人都是自定義新的結構體，將OVERLAPPED成員放置在第一位，然后后置其他成員。
在函數 WSASend, WSARecv, PostQueuedCompletionStatus 以及GetQueuedCompletionStatus 中都有LPOVERLAPPED的參數，其中在前面三個函數中是輸入參數，后面一個函數中是輸出參數。對于輸入參數可以傳入強制轉換的自定義結構體指針(不需要取地址)，也可以傳入自定義結構體中OVERLAPPED成員的地址(需要取地址)；對于輸出參數，將要傳出的是前三個函數中輸入參數的地址。在開發過程中，對于該結構地址的操作需要細心。
形如以下的代碼都是正確的：
WSASend(pClientData->IoSocket, &(pPerIoData->WsaSendDataBuff), 1, &dwSendBytes, 0, (LPOVERLAPPED)pPerIoData, NULL);
WSASend(pClientData->IoSocket, &(pPerIoData->WsaSendDataBuff), 1, &dwSendBytes, 0, &(pPerIoData->overlaped), NULL);
GetQueuedCompletionStatus(pThis->m_hIOCP, &dwBytesTransferred,(LPDWORD)&pPerHandleData, (LPOVERLAPPED *)&pPerIoData, INFINITE); 其次需要注意的是PostQueuedCompletionStatus 函數。該函數向IOCP發送三個參數(DWORD dwNumberOfBytesTransferred, ULONG_PTR dwCompletionKey, LPOVERLAPPED lpOverlapped)，GetQueuedCompletionStatus 函數將接收到這三個參數。IOCP將不會對這三個參數做任何操作。
在實際應用中，該函數一般用于控制IOCP接收線程的退出。其實，該函數的用法遠不止于此，它還可以作為消息來使用。通過定義特定的dwNumberOfBytesTransferred消息值，然后通過PostQueuedCompletionStatus函數向IOCP中POST該消息，GetQueuedCompletionStatus 函數就可以捕獲該消息。自定義的dwNumberOfBytesTransferred消息值一定要大于接收BUFFER和發送BUFFER的最大長度，否則作為消息就沒有意義了。
還有一個需要注意的是WSARecv函數。在IOCP中多次調用該函數是有后果的，嚴重的會導致接收緩沖區被塞滿，就算沒有塞滿接收緩沖區，如果客戶端意外斷開連接，GetQueuedCompletionStatus 函數會接到與調用次數一樣多次數的返回錯誤，想必大家一定都不希望這些情況發生。要避免這種問題一定要謹慎的調用WSARecv函數，最好在GetQueuedCompletionStatus 函數接收到數據后再考慮再次調用WSARecv。
今天又測出一個潛在的BUG，先貼代碼：
首先是定義：
typedef enum _IO_OPERATION
{
IoRecv, //WSARecv
IoSend, //WSASend
IoQuit
}IO_OPERATION, *PIO_OPERATION;
typedef struct _PER_IO_CONTEXT
{
WSAOVERLAPPED ol;
WSABUF WsaRecvDataBuff;
WSABUF WsaSendDataBuff;
char strRecvBuffer[DATA_MAX_BUFFERSIZE]; //接收BUFFER
char strSendBuffer[DATA_MAX_BUFFERSIZE]; //發送BUFFER
IO_OPERATION IoType;
}PER_IO_CONTEXT, *LPPER_IO_CONTEXT;
這里的IO_OPERATION定義了三種類型，分別表示接收、發送和退出，GetQueuedCompletionStatus函數在接收到消息時，可以通過檢測IoType的類型來判斷IOCP剛剛完成的操作是接收操作還是發送操作亦或是退出操作。
在一次操作中（比如接收到數據后的操作），先后調用WSASend和WSARecv，來實現發送數據，然后繼續Recv的動作，這樣做可行嗎？答案是否定的。分析：調用WSASend之前，設置IoType為IoSend，標志本次操作是發送操作；然后在調用WSARecv前，設置IoType為IoRecv，標志本次操作是接收操作。IOCP在處理消息隊列時，首先應該接收到的是發送操作，由于IoType已經被設置成了IoRecv，在判斷時就會將這次操作判斷成接收操作，去檢測接收BUFFER，這樣顯然就出錯了；然后會接收到接收操作，此時IoType是IoRecv，仍然判斷為接收操作，此時檢測接收BUFFER，是正確的。這樣做的直觀表現就是接收事件明顯變多了。
以上的這個例子，說明處理IOCP時一定要細心，要注意那些變量是易變的，那些是不易變的。可能上面的這個看起來很明顯，但是如果程序復雜了，這種BUG就不易察覺。