Win32 消息循環 WndProc 看似「死循環」實為正常消息泵機制

現象描述

調試 Win32 應用時，觀察黃色箭頭 (指令指針) 在 WndProc 函數內反覆跳轉：27→28→39→40→27→28→39→40...，偶爾進入 29-35 分支，看起來像「死循環」無法返回 WinMain。

真相：這是標準消息泵工作流

// WinMain 核心循環
while (GetMessage(&msg, NULL, 0, 0)) {  // ① 阻塞等待消息
    TranslateMessage(&msg);             // ② 處理鍵盤字符消息
    DispatchMessage(&msg);              // ③ 分發到 WndProc
}
// GetMessage 返回 0 (WM_QUIT) 時退出循環

調試器視角的「跳轉」解讀

1. GetMessage 陷入內核等待：無消息時，線程睡眠，**調試器不顯示內核代碼**，指令指針停留在 GetMessage 調用處；
2. 消息到達 → 內核喚醒線程 → 返回用戶態：指令指針跳到 TranslateMessage → DispatchMessage；
3. DispatchMessage 調用 WndProc：進入窗口過程函數，執行 switch(message) 分支；
4. WndProc 返回 → DispatchMessage 返回 → 循環回到 GetMessage：指令指針再次「跳回」循環開頭。

為何觀察到 27→28→39→40 反覆？

• 這些行號對應 GetMessage → TranslateMessage → DispatchMessage → WndProc 入口；
• 系統持續產生消息 (WM_PAINT, WM_TIMER, WM_MOUSEMOVE, WM_NCHITTEST 等)，**消息泵高速循環**；
• 偶爾進入 29-35 是處理特定消息 (如 WM_COMMAND, WM_KEYDOWN) 的分支代碼。

這不是 Bug，是特性

Win32 GUI 應用主線程 99% 時間在消息循環中度過。只要不處理 WM_QUIT，循環永不結束。這是事件驅動架構的核心：等待消息 → 分發處理 → 繼續等待。

調試建議

1. 設置條件斷點：message == WM_PAINT 或特定消息，避免高頻觸發干擾觀察；
2. 關注 WndProc 內部邏輯：而非循環結構本身；
3. 使用 Spy++ / Winspector：監控實際消息流，比單步調試更直觀；
4. 理解 GetMessage 返回值：>0 普通消息，=0 WM_QUIT 退出，<0 錯誤。

總結

調試器顯示的「死循環」實為 **Win32 消息泵正常高速運行**。主線程職責就是「死循環等消息、分發處理」。理解此機制，才能從「為什麼卡住」轉向「這條消息怎麼處理」。