1. 項目概述從零到一構(gòu)建一個MFC聊天程序最近在整理舊項目時翻出了一個多年前用VC和MFC寫的聊天程序。雖然現(xiàn)在各種即時通訊框架和庫層出不窮但回過頭來看用MFC這種經(jīng)典的桌面開發(fā)技術來實現(xiàn)一個完整的聊天應用依然是一個非常扎實的學習路徑。它能讓你深刻理解Windows消息機制、網(wǎng)絡編程、界面線程同步這些核心概念而不是僅僅停留在調(diào)用API的層面。這個項目標題“VC實現(xiàn)MFC聊天程序完整教程”聽起來像是一個老派的挑戰(zhàn)但它涵蓋的知識點——從界面布局到網(wǎng)絡通信從事件處理到數(shù)據(jù)序列化——對于想深入理解Windows桌面開發(fā)本質(zhì)的開發(fā)者來說價值一點都沒過時。這個程序本質(zhì)上是一個C/S架構(gòu)的桌面應用包含服務器端和客戶端。服務器負責管理連接和轉(zhuǎn)發(fā)消息客戶端則提供用戶交互界面。我們將使用MFC的文檔/視圖架構(gòu)作為基礎利用Windows Socket進行網(wǎng)絡通信。整個過程會涉及到MFC對話框編程、控件使用、自定義消息、多線程處理以及基礎的TCP套接字編程。即使你之前只用過Qt或WinForms跟著這個流程走一遍也能對Windows原生開發(fā)有全新的認識。我將會把當年踩過的坑、調(diào)試的心得以及如何讓程序更健壯的經(jīng)驗都揉進這個教程里。2. 核心需求解析與技術選型考量2.1 功能需求拆解一個聊天程序無論簡單還是復雜其核心需求是穩(wěn)定的。我們需要實現(xiàn)以下幾個基本功能模塊用戶界面這是用戶直接交互的部分。需要一個主窗口顯示聊天記錄一個輸入框用于編輯消息發(fā)送按鈕以及連接服務器的配置區(qū)域如服務器IP地址和端口輸入框、連接/斷開按鈕。可能還需要一個在線用戶列表。網(wǎng)絡通信這是程序的心臟。必須實現(xiàn)基于TCP或UDP協(xié)議的套接字通信。TCP能保證消息可靠、有序地送達更適合聊天場景。我們需要處理連接建立、數(shù)據(jù)收發(fā)、連接斷開以及錯誤處理。消息協(xié)議網(wǎng)絡上傳送的是二進制字節(jié)流。我們需要定義一種簡單的應用層協(xié)議讓客戶端和服務器能理解彼此發(fā)送的數(shù)據(jù)。例如一條消息可以包含“發(fā)送者”、“接收者”、“消息內(nèi)容”、“時間戳”等字段。并發(fā)處理服務器需要同時處理多個客戶端的連接。這意味著必須使用多線程或異步I/O模型。在客戶端為了不阻塞UI網(wǎng)絡接收操作也最好放在單獨的線程中。數(shù)據(jù)持久化雖然不是最核心的但一個實用的聊天程序通常需要保存聊天記錄。我們可以選擇將記錄保存到本地文件或數(shù)據(jù)庫中。2.2 為什么選擇VC與MFC看到“VC”和“MFC”很多新入行的朋友可能會覺得這是“上古”技術。確實它不是當下最時髦的選擇但對于這個特定項目和學習目的而言它有不可替代的優(yōu)勢深入理解Windows編程模型MFC是對Win32 API的一層面向?qū)ο蠓庋b。通過它你能更直觀地理解窗口、消息循環(huán)、設備上下文、GDI對象等Windows核心概念。很多現(xiàn)代框架如Qt、WinUI底層依然繞不開這些。資源與生態(tài)Visual Studio對MFC的支持非常成熟資源編輯器對話框、菜單、圖標編輯器用起來非常高效。大量的遺留系統(tǒng)、工業(yè)控制軟件仍在使用MFC掌握它意味著你能維護和開發(fā)這類應用。輕量級與可控性相比.NET Framework或一些大型UI庫純粹的MFC程序依賴少體積小運行效率高。你對程序的行為有完全的控制權(quán)從內(nèi)存分配到消息處理一切盡在掌握。學習曲線與成就感MFC的學習曲線確實陡峭但一旦你征服了它再去學習其他GUI框架會感覺容易很多。完整實現(xiàn)一個網(wǎng)絡聊天程序帶來的成就感是單純調(diào)用一個現(xiàn)成IM SDK無法比擬的。注意本教程基于Visual Studio 2019/2022進行它們?nèi)匀煌昝乐С諱FC開發(fā)。如果你遇到“vs2019創(chuàng)建mfc項目沒有窗體”的問題請確保在安裝Visual Studio時勾選了“使用C的桌面開發(fā)”工作負載下的“MFC和ATL支持”組件。2.3 網(wǎng)絡協(xié)議選擇TCP vs UDP這是一個關鍵決策。對于聊天程序我們強烈推薦使用TCP。TCP面向連接、可靠、有序的字節(jié)流。建立連接需要三次握手能保證數(shù)據(jù)包不丟失、不重復、按序到達。這正是聊天消息傳輸所需要的特性——你肯定不希望“你好”和“再見”兩條消息的順序顛倒或丟失其中一條。UDP無連接、不可靠、盡最大努力交付。它速度快、開銷小但不保證送達和順序。適合視頻流、語音聊天或?qū)崟r游戲這種可以容忍少量丟包的場景。在我們的項目中我們將采用TCP協(xié)議。服務器將監(jiān)聽一個端口客戶端通過該端口與服務器建立連接。服務器作為消息中轉(zhuǎn)站接收一個客戶端的消息然后轉(zhuǎn)發(fā)給目標客戶端或所有其他客戶端。3. 開發(fā)環(huán)境搭建與項目創(chuàng)建3.1 安裝必要的運行庫與組件在開始編碼之前確保你的開發(fā)環(huán)境齊全。正如網(wǎng)絡熱詞中提到的“微軟 vc 2015-2022 x64 運行庫”你的程序最終需要在用戶機器上運行而用戶可能沒有安裝相應的VC運行庫。你有兩個選擇靜態(tài)鏈接在項目屬性中將“運行時庫”設置為“多線程(/MT)”或“多線程調(diào)試(/MTd)”。這樣會將必要的C運行庫代碼編譯進你的EXE文件中生成的文件會變大但部署簡單用戶無需額外安裝運行庫。動態(tài)鏈接并分發(fā)使用“多線程DLL(/MD)”模式。你需要將對應的MSVCPxxx.dll和VCRUNTIMExxx.dll等文件隨你的程序一起分發(fā)或者引導用戶安裝“Microsoft Visual C Redistributable”運行庫合集。對于新手我建議先使用靜態(tài)鏈接以簡化部署和調(diào)試。在Visual Studio Installer中請確認已安裝“使用C的桌面開發(fā)”工作負載并勾選了“用于x86和x64的Visual C MFC”和“Windows 10 SDK”或最新版Windows SDK。3.2 創(chuàng)建MFC應用程序項目打開Visual Studio選擇“創(chuàng)建新項目”。搜索“MFC”選擇“MFC應用程序”點擊“下一步”。給項目起個名字比如MFCChat選擇合適的位置。在“應用程序類型”頁面做如下關鍵選擇應用程序類型選擇“基于對話框”。對于聊天客戶端這種主界面是一個對話框的程序來說這比“單文檔”或“多文檔”更簡單直接。服務器端如果不需要復雜界面甚至可以用控制臺程序但這里為了教學統(tǒng)一我們也用基于對話框的MFC程序來創(chuàng)建服務器。項目樣式選擇“MFC標準”。使用共享DLL中的MFC這里根據(jù)你之前的決定選擇。為了部署方便教程示例選擇“在靜態(tài)庫中使用MFC”。文檔/視圖結(jié)構(gòu)支持因為我們用的是基于對話框的程序這個選項不可用或無需勾選。點擊“完成”VS會為你生成一個帶有基礎對話框和標準MFC類骨架的項目。3.3 界面設計初步使用對話框編輯器項目創(chuàng)建后你會看到資源視圖里有一個IDD_MFCCHAT_DIALOG的對話框資源。雙擊打開對話框編輯器。對于客戶端我們需要拖放以下控件List Box或List Control用于顯示聊天記錄。IDC_CHAT_LIST。Edit Control用于輸入消息。設置為多行、垂直滾動。IDC_MSG_EDIT。Button發(fā)送消息按鈕。IDC_SEND_BTN標題為“發(fā)送(S)”。Edit Control用于輸入服務器IP。IDC_IP_EDIT。Edit Control用于輸入服務器端口。IDC_PORT_EDIT。Button連接服務器按鈕。IDC_CONNECT_BTN標題為“連接”。Button斷開連接按鈕。IDC_DISCONNECT_BTN標題為“斷開”初始狀態(tài)為禁用(Disabled)。對于服務器端界面可以更簡單List Box顯示服務器日志如客戶端連接、斷開、消息轉(zhuǎn)發(fā)記錄。IDC_LOG_LIST。Button啟動服務器按鈕。IDC_START_BTN。Button停止服務器按鈕。IDC_STOP_BTN初始狀態(tài)為禁用。使用編輯器調(diào)整控件布局使其美觀易用。記住每個控件的ID我們稍后需要為它們關聯(lián)變量和事件處理程序。4. 網(wǎng)絡通信核心Windows Sockets編程4.1 MFC對Socket的封裝CAsyncSocket與CSocketMFC提供了兩個主要的套接字類CAsyncSocket和CSocket。CAsyncSocket是對Winsock API的低層封裝提供了基于事件回調(diào)的異步模型控制靈活但需要自己處理更多細節(jié)。CSocket派生自CAsyncSocket它提供了更高級的、與MFC歸檔序列化機制集成的同步操作并且是線程安全的簡化了編程。對于我們的聊天程序服務器端由于要處理多個客戶端連接我們采用每個客戶端連接一個獨立工作線程的模式。在這個工作線程中我們可以使用CSocket進行同步的Receive和Send操作邏輯清晰。監(jiān)聽Socket在主線程使用異步事件。客戶端通常只有一個連接Socket。我們可以選擇在UI線程中使用CAsyncSocket的異步模型通過重寫OnReceive等虛函數(shù)或者單獨創(chuàng)建一個工作者線程使用CSocket進行同步通信。為了避免接收數(shù)據(jù)阻塞UI我推薦為客戶端也創(chuàng)建一個獨立的網(wǎng)絡通信線程。本教程將采用多線程 CSocket的方案因為它邏輯更直白更容易處理阻塞操作和線程同步。4.2 定義簡單的應用層消息協(xié)議在網(wǎng)絡上我們不能直接發(fā)送C對象。我們需要將消息結(jié)構(gòu)體序列化成字節(jié)流。我們定義一個簡單的協(xié)議// 定義消息類型 enum MsgType { MSG_TYPE_TEXT 1, // 文本消息 MSG_TYPE_LOGIN, // 登錄/加入聊天室 MSG_TYPE_LOGOUT, // 登出/離開 MSG_TYPE_USERLIST // 用戶列表更新 }; // 消息頭固定長度 struct ChatMsgHeader { int msgType; // 消息類型 int msgLen; // 消息體長度不包括頭部 char sender[32]; // 發(fā)送者昵稱 char receiver[32]; // 接收者昵稱廣播消息可為空或特定標識 }; // 文本消息體可變長度由msgLen指定 // 緊跟在Header后面的是實際的文本內(nèi)容char數(shù)組發(fā)送一條消息的流程在發(fā)送端填充ChatMsgHeader結(jié)構(gòu)體計算消息體長度msgLen。先發(fā)送ChatMsgHeadersizeof(ChatMsgHeader)字節(jié)。再發(fā)送消息體msgLen字節(jié)。接收一條消息的流程先嘗試接收固定大小的ChatMsgHeader。必須循環(huán)接收直到收滿sizeof(header)字節(jié)因為TCP是流式協(xié)議可能分多次到達。解析header.msgLen。根據(jù)msgLen循環(huán)接收消息體數(shù)據(jù)直到收滿。根據(jù)header.msgType處理不同類型的消息。這個“長度前綴”的方法是處理TCP粘包/拆包問題的常見手段。4.3 服務器端核心實現(xiàn)監(jiān)聽與客戶端管理服務器需要做以下幾件事創(chuàng)建監(jiān)聽Socket在主線程通常是對話框類中創(chuàng)建一個CSocket對象如m_listenSocket調(diào)用Create和Bind指定端口然后調(diào)用Listen開始監(jiān)聽。接受連接我們需要一種機制來接受新連接。可以在一個單獨的“接受線程”中循環(huán)調(diào)用m_listenSocket.Accept(m_clientSocket)或者使用CAsyncSocket的OnAccept事件。為了簡單我們可以在一個工作者線程中做同步Accept。為每個客戶端創(chuàng)建線程一旦Accept成功得到一個新的CSocket對象代表與該客戶端的連接立即創(chuàng)建一個新的工作者線程CWinThread將這個Socket對象通常需要傳遞其句柄或指針注意線程安全交給該線程處理。客戶端線程工作循環(huán)在線程函數(shù)中循環(huán)執(zhí)行Receive消息頭。Receive消息體。解析消息。根據(jù)消息類型處理如廣播文本消息、更新用戶列表。將消息轉(zhuǎn)發(fā)給其他在線的客戶端遍歷客戶端連接列表調(diào)用每個客戶端Socket的Send方法。管理客戶端列表服務器需要維護一個當前在線客戶端的列表包含Socket指針、用戶昵稱等信息。這個列表會被多個客戶端線程讀寫因此必須使用線程同步機制如臨界區(qū)CCriticalSection或互斥量CMutex來保護。一個常見的坑是直接在不同線程間傳遞或使用MFC對象如CSocket。MFC對象通常與創(chuàng)建它的線程關聯(lián)。解決方案是在主線程創(chuàng)建Socket然后將其句柄SOCKET類型傳遞給工作者線程在線程中再通過CSocket::FromHandle或Attach來關聯(lián)一個棧上的CSocket對象進行操作。更安全的方式是直接在線程中使用Winsock API。4.4 客戶端核心實現(xiàn)連接、發(fā)送與接收客戶端相對簡單連接服務器用戶點擊“連接”按鈕在按鈕事件處理函數(shù)中獲取IP和端口創(chuàng)建一個CSocket對象如m_clientSocket調(diào)用Create()和Connect(serverIp, port)。啟動接收線程連接成功后立即創(chuàng)建一個獨立的接收線程。將m_clientSocket的句柄傳遞給這個線程。UI線程不應該進行阻塞的Receive調(diào)用否則界面會卡死。接收線程工作循環(huán)與服務器端的客戶端線程類似循環(huán)接收消息頭和消息體。收到完整消息后需要將其傳遞回UI線程進行顯示例如將消息內(nèi)容添加到聊天記錄List Box中。切記不能在工作線程中直接操作UI控件這會導致程序不穩(wěn)定或崩潰。跨線程更新UIMFC中從工作線程安全更新UI的標準方法是使用自定義消息WM_USER xxx或PostMessage。工作線程將收到的消息數(shù)據(jù)打包通過PostMessage發(fā)送到主對話框窗口。主對話框的WindowProc或消息映射中處理該自定義消息從中解包數(shù)據(jù)并更新控件。發(fā)送消息用戶在編輯框中輸入內(nèi)容點擊“發(fā)送”。在“發(fā)送”按鈕事件處理函數(shù)中獲取文本按照協(xié)議格式打包成字節(jié)流。然后調(diào)用m_clientSocket.Send()發(fā)送。這里Send是同步的但因為它很快在UI線程中直接調(diào)用通常可以接受。如果擔心阻塞也可以將發(fā)送操作放到另一個線程或使用異步Socket。5. 關鍵難點與實戰(zhàn)技巧5.1 多線程同步與資源管理這是MFC網(wǎng)絡編程中最容易出錯的地方。Socket傳遞如前所述不要跨線程直接使用同一個CSocket對象。推薦模式是主線程創(chuàng)建Socket并連接后將其Detach()把原始的SOCKET句柄一個整數(shù)值傳遞給工作線程。工作線程內(nèi)創(chuàng)建一個局部的CSocket對象調(diào)用Attach(hSocket)將其與句柄關聯(lián)然后進行通信。線程結(jié)束時確保在局部CSocket對象析構(gòu)前不要Close或者先Detach再關閉句柄。UI更新必須通過消息機制。例如// 定義自定義消息 #define WM_UPDATE_CHAT_MSG (WM_USER 100) // 在工作線程中 CString* pMsg new CString(_T(Hello from thread!)); ::PostMessage(hWndMain, WM_UPDATE_CHAT_MSG, (WPARAM)pMsg, 0); // 在主對話框消息映射中 ON_MESSAGE(WM_UPDATE_CHAT_MSG, OnUpdateChatMsg) LRESULT CMFCChatDlg::OnUpdateChatMsg(WPARAM wParam, LPARAM lParam) { CString* pMsg (CString*)wParam; m_listChat.AddString(*pMsg); delete pMsg; // 務必記得刪除避免內(nèi)存泄漏 return 0; }資源泄漏確保每個new/malloc都有對應的delete/free。對于Socket確保在程序退出或連接斷開時正確關閉。對于線程確保在對話框銷毀時能正常通知工作線程退出例如設置一個退出標志volatile bool m_bStop并等待線程結(jié)束WaitForSingleObject。5.2 TCP粘包/拆包處理這是網(wǎng)絡編程的經(jīng)典問題。由于TCP是字節(jié)流沒有消息邊界一次Send的數(shù)據(jù)可能被分成多個包到達拆包或者多次Send的小數(shù)據(jù)可能被合并成一個包到達粘包。我們的“長度前綴法”就是為了解決這個問題。在接收端必須嚴格按照“先收固定頭解析長度再收對應長度體”的流程并且要用循環(huán)來收因為一次Receive調(diào)用可能只收到部分數(shù)據(jù)。// 偽代碼接收固定長度數(shù)據(jù)的函數(shù) int ReceiveExact(CSocket sock, char* buf, int len) { int totalReceived 0; while (totalReceived len) { int ret sock.Receive(buf totalReceived, len - totalReceived); if (ret 0) { // 連接錯誤或關閉 return -1; } totalReceived ret; } return totalReceived; // 應該等于len } // 在接收線程中 ChatMsgHeader header; if (ReceiveExact(clientSocket, (char*)header, sizeof(header)) 0) break; char* pBody new char[header.msgLen 1]; // 多一個字節(jié)放字符串結(jié)束符 if (ReceiveExact(clientSocket, pBody, header.msgLen) 0) { delete[] pBody; break; } pBody[header.msgLen] \0; // 處理header和pBody... delete[] pBody;5.3 程序穩(wěn)定性與異常處理網(wǎng)絡程序必須健壯能處理各種異常情況。心跳機制長時間沒有數(shù)據(jù)通信TCP連接可能因為中間網(wǎng)絡設備超時而被斷開但應用程序感知不到。可以設計一個簡單的心跳包MsgType為MSG_TYPE_PING/PONG定期發(fā)送以保持連接活躍并檢測死連接。超時設置CSocket可以調(diào)用SetSockOpt設置發(fā)送和接收超時避免在網(wǎng)絡異常時無限期阻塞。錯誤處理每次Socket操作Connect,Accept,Send,Receive后都應檢查返回值或調(diào)用GetLastError。對于Receive返回0表示對方優(yōu)雅地關閉了連接。線程安全退出對話框關閉時向所有工作線程發(fā)送退出信號并等待它們結(jié)束。避免線程還在訪問已被銷毀的對話框成員變量。6. 界面優(yōu)化與功能增強6.1 聊天記錄顯示的優(yōu)化使用簡單的List Box顯示聊天記錄當消息多時會很簡陋。我們可以使用List Control換成CListCtrl可以設置多列分別顯示時間、發(fā)送者、消息內(nèi)容看起來更專業(yè)。富文本顯示如果想支持表情、圖片或字體顏色可以考慮使用CRichEditCtrl。但這會復雜很多需要處理RTF格式或自定義繪制。自動滾動添加新消息后自動滾動到底部。對于CListBox可以調(diào)用SetTopIndex(GetCount() - 1)。時間戳在打包消息時加入時間戳在顯示時格式化輸出。6.2 實現(xiàn)用戶列表與私聊功能目前我們實現(xiàn)的是廣播聊天室。要支持用戶列表和私聊需要登錄協(xié)議客戶端連接后發(fā)送一個MSG_TYPE_LOGIN消息攜帶用戶昵稱。服務器將其加入在線用戶列表。維護用戶列表服務器端維護一個std::mapSOCKET, UserInfo其中UserInfo包含昵稱、狀態(tài)等。廣播用戶列表更新當有用戶加入或離開時服務器構(gòu)造一個MSG_TYPE_USERLIST消息將當前在線用戶列表可以只發(fā)昵稱發(fā)送給所有客戶端。客戶端顯示列表客戶端收到用戶列表消息后更新一個List Box控件。私聊協(xié)議在消息頭ChatMsgHeader中我們已經(jīng)定義了receiver字段。發(fā)送私聊消息時客戶端將receiver字段設置為目標用戶的昵稱。服務器收到后不是廣播而是查找昵稱對應的Socket單獨發(fā)送給該接收者。6.3 文件傳輸與圖片發(fā)送這是一個高級功能。基本思路是定義新的消息類型如MSG_TYPE_FILE_INFO和MSG_TYPE_FILE_DATA。MSG_TYPE_FILE_INFO包含文件名、文件大小等信息。接收方確認后發(fā)送方將文件分塊通過多個MSG_TYPE_FILE_DATA消息發(fā)送。接收方按順序接收并重組文件。需要注意的是大文件傳輸不能阻塞主消息循環(huán)需要單獨的任務隊列或線程處理。圖片可以當作二進制文件傳輸也可以在客戶端先壓縮如轉(zhuǎn)為Base64再以文本消息形式發(fā)送但后者效率低。7. 調(diào)試、部署與常見問題7.1 VC程序崩潰調(diào)試網(wǎng)絡熱詞中提到了“vc 崩潰生成調(diào)試文件”。當程序在用戶機器上崩潰時獲取崩潰現(xiàn)場信息至關重要。生成調(diào)試符號PDB文件在項目屬性 - “鏈接器” - “調(diào)試”中確保“生成調(diào)試信息”設置為“是(/DEBUG)”。發(fā)布版本也可以生成PDB這不會影響性能。設置異常處理與生成Dump文件可以使用SetUnhandledExceptionFilter函數(shù)設置頂層的未處理異常過濾器。當崩潰發(fā)生時在這個過濾器函數(shù)中調(diào)用MiniDumpWriteDump函數(shù)將進程的內(nèi)存狀態(tài)寫入一個.dmp文件。將這個.dmp文件和對應的PDB文件拿回開發(fā)機用Visual Studio打開就能看到崩潰時的調(diào)用棧和變量信息極大方便了定位問題。日志系統(tǒng)在關鍵路徑添加日志輸出輸出到文件或調(diào)試器記錄程序狀態(tài)、網(wǎng)絡數(shù)據(jù)等是排查線上問題的利器。7.2 64位與32位兼容性問題熱詞中提到了“mfc的64位的exe不能調(diào)用32位的dll嗎?”。是的絕對不能混用。一個進程的地址空間是統(tǒng)一的如果進程是64位的它加載的所有DLL也必須是64位的32位進程只能加載32位DLL。這是由CPU指令集和操作系統(tǒng)加載器決定的。如果你的程序需要調(diào)用一個只有32位版本且沒有源碼的DLL那么你的主程序也必須編譯成32位即x86平臺。在Visual Studio的項目屬性 - “配置管理器”中將活動解決方案平臺設置為“Win32”。如果你的程序是64位的而DLL是32位的唯一的辦法是創(chuàng)建一個單獨的32位進程代理進程來加載那個DLL然后通過進程間通信IPC來調(diào)用功能這非常復雜。7.3 程序打包與依賴檢查使用靜態(tài)鏈接MFC和運行時庫是最簡單的部署方式生成的單個EXE文件可以在大多數(shù)Windows系統(tǒng)上直接運行。如果使用動態(tài)鏈接你需要確保目標機器上有相應的庫。可以使用Visual Studio自帶的“發(fā)布”功能或者使用第三方安裝包制作工具如Inno Setup, NSIS將必要的MSVCPxxx.dll,MFCxxx.dll,VCRUNTIMExxx.dll等文件打包進安裝程序。在開發(fā)機上測試通過后務必在一臺干凈的、沒有安裝Visual Studio的虛擬機或電腦上測試確認所有依賴都已就位。7.4 常見編譯與運行錯誤“f:\dd\vctools\vc7libs\ship\atimfc\src\mfc\afxshellmanager.cpp line: 30”這類錯誤通常指向MFC內(nèi)部源碼往往是因為資源ID定義沖突、在錯誤的線程中調(diào)用了MFC函數(shù)、或者MFC對象如CWnd使用不當如訪問了已銷毀的窗口。仔細檢查你的消息映射、線程間對象傳遞和控件訪問。鏈接錯誤“無法解析的外部符號”檢查你是否在stdafx.h或項目設置中包含了必要的頭文件如afxsock.h用于Socket支持以及是否鏈接了對應的庫如Socket庫ws2_32.lib是自動鏈接的但如果你用了其他庫則需要手動添加。運行時Socket錯誤10038在一個已關閉或未初始化的Socket上操作。檢查你的Socket對象生命周期確保在調(diào)用Send/Receive前Socket是有效的。界面卡死或無響應這幾乎肯定是因為在UI線程中執(zhí)行了阻塞操作如長時間循環(huán)、同步網(wǎng)絡接收。牢記所有可能阻塞的操作都應放到工作線程中。實現(xiàn)一個完整的MFC聊天程序是一次對Windows桌面開發(fā)核心技術的全面演練。從消息循環(huán)到網(wǎng)絡I/O從多線程同步到資源管理每一步都需要仔細考量。雖然過程會遇到不少挑戰(zhàn)但當你最終看到兩個自己編寫的程序成功互發(fā)消息時那種對系統(tǒng)底層運作機制的理解和掌控感是使用高級框架快速搭出應用所無法比擬的。這個項目代碼量不大但涉及的知識點很密集非常適合作為深入C Windows編程的練手項目。