简介CAsyncSocket 使用例子面向具备一定 MFC 与 Windows 网络编程基础的开发者围绕异步套接字封装演示 TCP 客户端与服务端的完整通信流程。内容重点涉及套接字创建、连接与监听、Accept 接受新连接、Receive/Send 数据收发以及 OnConnect、OnAccept、OnReceive、OnSend、OnClose 等事件驱动处理并兼顾错误码检查、多客户端管理与文件分块传输思路。压缩包共 44 个文件以 11 个 h 头文件和 9 个 cpp 源文件为核心配有 ico、rc、dsp、dsw 等工程与资源文件及说明文本整体约 1.82MB便于直接打开工程对照学习。已有 445 人学习适合用作课程设计、网络通信实验或 MFC 异步 Socket 入门的参考范例可据此梳理客户端/服务端结构并理解事件回调与排错要点。1. 从「连上了但收不到数据」说起CAsyncSocket 到底替你做了什么上个月有个做工业上位机的同行拿来一段 MFC 老代码CAsyncSocket 的客户端和服务端都 Create 成功了Connect 也返回了界面上却一条数据都不刷新日志里连 OnReceive 的影子都没有。他以为是协议写错查了两天最后发现 socket 建在了工作线程里那个线程压根没跑消息循环。这份 CAsyncSocket 使用例子最容易被忽略的一点就是它本质上是 WSAAsyncSelect 的一层薄封装——OnAccept、OnConnect、OnReceive、OnSend、OnClose 全部是窗口消息的回调没有消息泵就没有一切。这份资源把服务端监听、客户端连接、收发拆包、断线清理这条链路串成可直接抄的结构适合正在维护 MFC 老项目、又不想把整个网络层推倒重写的开发者。2. 事件驱动的地基WSAAsyncSelect、消息泵与三个初始化细节在写下第一行Create之前得先接受一个事实CAsyncSocket 不是「调用一个函数就完事」的同步 socket它是把 WinSock 的异步事件翻译成窗口消息再由 MFC 分发到你的虚函数上。这条链路里任何一环断掉表现出来的都是「代码没错就是不回调」比崩溃更难查。所以这一章先把地基打牢再谈业务。2.1 AfxSocketInit 与消息泵异步回调靠谁来敲门MFC 里所有 socket 操作之前必须调用一次AfxSocketInit它内部完成WSAStartup并把 Winsock 版本协商好。位置很讲究放在CWinApp::InitInstance的最前面比任何窗口、任何 CAsyncSocket 成员对象都早。因为全局或成员对象的构造可能早于InitInstance一旦在AfxSocketInit之前就Create拿到的是WSANOTINITIALISED而且这个错误码经常被忽略掉。BOOL CMyApp::InitInstance() { // 必须在任何 CAsyncSocket 对象创建之前调用内部完成 WSAStartup if (!AfxSocketInit()) { AfxMessageBox(_T(Winsock 初始化失败)); return FALSE; } CWinApp::InitInstance(); // 之后再创建主窗口、再 new 出服务端 socket return TRUE; }AfxSocketInit的参数是一个可选的WSADATA*一般传 NULL 就行返回 FALSE 表示 Winsock 环境没起来此时继续往下走只会得到一串莫名其妙的错误码。真正让新手翻车的是第二个细节MFC 在内部创建了一个隐藏窗口来接收FD_*消息再由它分发给对应的 CAsyncSocket 对象。这个隐藏窗口是线程局部的消息必须被该线程的消息循环取出来并DispatchMessage回调才会发生。主 UI 线程天然有CWinApp::Run在泵消息所以主线程里写例子一切正常一旦你为了「不卡界面」把 socket 挪到AfxBeginThread开出来的工作线程就变成另一回事了。UINT CNetWorker::Run() { // 每个使用 socket 的线程都要独立初始化一次 Winsock 环境 if (!AfxSocketInit()) return 1; CMyClientSock sock; if (!sock.Create()) return 1; sock.Connect(_T(127.0.0.1), 9000); // 关键线程必须自己泵消息否则 OnConnect/OnReceive 永远不会被调用 MSG msg; while (::GetMessage(msg, NULL, 0, 0)) { ::TranslateMessage(msg); ::DispatchMessage(msg); } return 0; }逻辑说明AfxSocketInit在每个线程里都要调一次MFC 的模块状态是线程局部的主线程初始化过不代表工作线程也初始化了。参数说明GetMessage的第二个参数传 NULL 表示取本线程所有窗口消息包括那个隐藏 socket 窗口的消息如果传了某个窗口句柄socket 消息就取不到。另一个隐蔽点循环里如果有Sleep、WaitForSingleObject卡住很久回调也会跟着延迟表现成「偶尔丢包」其实是你自己把消息泵堵住了。2.2 事件掩码怎么选FD_READ、FD_WRITE、FD_ACCEPT、FD_CLOSE 的触发时机Create的第三个参数lEvent是事件掩码默认值包含 READ、WRITE、OOB、ACCEPT、CONNECT、CLOSE 六个。默认值能跑但对客户端来说 ACCEPT 永远用不上对监听套接字来说 READ/WRITE 又没意义掩码开得越精确内核里做的判断越少出问题的面也越小。更重要的是要搞清楚每个事件是「电平触发」还是「边沿触发」这直接决定了你的事件处理函数里该写什么。事件触发时机是否边沿触发常见误用FD_READ接收缓冲区有数据可读否未读完会再次触发只 recv 一次就返回剩余数据留在缓冲区FD_WRITE连接建立成功或发送缓冲区由满变空是把每个数据包都挂到 OnSend 上再发FD_ACCEPT有新的待处理连接否不在 OnAccept 里循环 AcceptFD_CONNECT连接完成成功或失败是只来一次不看错误码就当作连接成功FD_CLOSE对端发送 FIN 关闭是在 OnClose 里直接 delete thisFD_WRITE的边沿触发是最多人栽跟头的地方。它的语义不是「你随时可以发」而是「发送缓冲区从不可写变成可写」。连接成功后它会来一次之后只有在某次Send返回WSAEWOULDBLOCK、缓冲区被排空之后它才会再来。如果你的代码从不超过缓冲区上限那OnSend一辈子只触发一次把业务数据挂在OnSend里发的写法必然只发出第一条。FD_CONNECT同样需要看错误码。很多人以为OnConnect被调用就是连上了实际上连接被拒绝、超时、主机不可达都会走到这里区别只在GetLastError()的返回值成功时是 0。2.3 一个能跑通的最小服务端骨架把地基铺好后先写一个最小服务端把链路验证通再往里塞业务。下面这段是我常用的起点监听套接字一个连接套接字按需 new事件处理只打日志先确认回调能进来。class CListenSock : public CAsyncSocket { public: virtual void OnAccept(int nErrorCode) { if (nErrorCode ! 0) { CAsyncSocket::OnAccept(nErrorCode); return; } // 每个连接都必须 new 一个新的 CAsyncSocket 派生对象来承接 CConnSock* pConn new CConnSock(); if (!Accept(*pConn)) { // Accept 失败要立刻回收否则是稳定的内存泄漏 delete pConn; } else { g_connMap[pConn-m_hSocket] pConn; // 交给连接表托管 TRACE(_T(accept fd%d\n), pConn-m_hSocket); } CAsyncSocket::OnAccept(nErrorCode); } }; BOOL CServerApp::StartListen(UINT nPort) { m_pListen new CListenSock(); // 第三参数只开 ACCEPT 和 CLOSE监听套接字不碰收发 if (!m_pListen-Create(nPort, SOCK_STREAM, FD_ACCEPT | FD_CLOSE)) { TRACE(_T(Create failed, err%d\n), m_pListen-GetLastError()); return FALSE; } if (!m_pListen-Listen(5)) { TRACE(_T(Listen failed, err%d\n), m_pListen-GetLastError()); return FALSE; } return TRUE; }逻辑说明监听套接字只负责FD_ACCEPT每次回调里new一个连接对象并调用Accept把它「接」过来接好之后这个新对象就拥有了独立的 socket 句柄和独立的事件。参数说明Create的第一个参数是端口传 0 表示由系统分配客户端一般传 0第二个参数SOCK_STREAM就是 TCPListen的参数是 backlog传 5 在老代码里很常见现代机器上可以给到 32 或 64但对内网几十个连接的上位机场景差别不大。这里要提醒一点Accept的第一个参数是引用接收方对象必须已经构造出来MFC 内部会把这个新连接句柄Attach到它身上并注册事件掩码。如果你在OnAccept里复用了监听对象本身第一次能连上第二次就会因为句柄被覆盖而整个服务端失聪。3. 服务端 accept 的完整链路监听套接字与连接对象怎么分开管理服务端最容易写错的地方不在 accept 本身而在于「谁拥有谁、谁负责删谁」。监听套接字活在很长的时间里连接套接字活在一次会话里两者的生命周期完全不同混在一起写就会出重复析构、野指针、句柄泄漏。3.1 Create、Listen、OnAccept 三步的参数含义Create在内部已经完成了socket和bind两步所以你会看到有的教程在Create前面还手动bind一次那是CSocket或原生 API 的写法直接套到 CAsyncSocket 上会bind两次失败。Create的第四个参数是绑定地址默认 NULL即绑定所有本地网卡如果机器有多张网卡、只想在指定网段监听就填上具体 IP。Listen只对监听套接字有效对已经Accept出来的连接对象调用是没意义的。backlog 参数的含义是已完成三次握手但还没被 accept 的队列长度超过这个长度之后新连接会被内核直接忽略或拒绝表现出来是客户端偶发连接超时。老代码里写 5 意味着并发握手高峰只有 5 个排队位压力大时会明显漏连。OnAccept的nErrorCode参数一定要先判断。这个回调在出错时也会被调用比如监听套接字被意外关闭此时Accept必然失败如果不看错误码直接往下走new出来的对象会被立刻删掉日志里刷一片无意义的 accept 失败。3.2 在 OnAccept 里 new 一个对象以及它的销毁时机连接对象的销毁是整个服务端最需要小心的一处。有三种情况会导致连接结束对端正常关闭OnClose、本端主动关闭业务决定踢人、发生错误OnClose带非零错误码。这三条路最后都要汇到同一个动作从连接表里摘掉、Close、然后delete。但delete的时机不能放在回调函数内部。原因很直接OnClose返回之后MFC 的分发代码还要访问这个对象的成员比如判断句柄是否还有效你在这里把this删了后续访问就是野指针。血泪经验是别指望调试器能帮你定位这种崩溃的调用栈往往指向 MFC 内部看起来跟你写的代码毫无关系。我一般的做法是回调里只做Close()和「打标记」真正的删除交给主线程消息。// 自定义消息主窗口收到后再做实际删除 #define WM_SOCK_DELETE (WM_USER 100) void CConnSock::OnClose(int nErrorCode) { if (g_connMap.count(m_hSocket)) g_connMap.erase(m_hSocket); // 只关闭句柄不 delete 自己 Close(); // 把自己交给主线程延后删除避免在 MFC 分发过程中析构 if (g_pMainWnd) g_pMainWnd-PostMessage(WM_SOCK_DELETE, (WPARAM)this, 0); CAsyncSocket::OnClose(nErrorCode); } // 主窗口的消息处理 LRESULT CMainWnd::OnSockDelete(WPARAM wParam, LPARAM) { CConnSock* p reinterpret_castCConnSock*(wParam); delete p; // 到这一步MFC 的这次分发早就返回了 return 0; }逻辑说明Close()会关闭句柄并把内部句柄置为无效对象本身还活着可以安全地继续访问成员。PostMessage是异步投递等消息被处理时OnClose的调用栈早已退出。参数说明WM_SOCK_DELETE用WM_USER 100只是习惯只要不和已有自定义消息冲突就行wParam存指针在 32 位程序里没问题64 位程序里指针是 8 字节WPARAM也是 8 字节同样安全。3.3 连接表管理把 socket 指针映射到业务上下文服务端不可能只有一个连接必须有一张表把句柄或对象指针映射到业务状态。常见做法是用std::mapSOCKET, CConnSock*或CMapSOCKET, SOCKET, CConnSock*, CConnSock*。key 用m_hSocket而不是对象地址因为对象地址在new之后虽然稳定但用句柄查找更符合直觉而且日志里打句柄也方便对照netstat。连接表要处理三个动作accept 时插入、close 时摘除、程序退出时遍历关闭。程序退出这一步特别容易漏很多人只delete监听对象连接对象全部泄漏进程结束时操作系统会回收句柄所以平时看不出来一旦你的程序作为服务常驻、又支持热重启泄漏就会累积。void CServerApp::StopAll() { // 先停监听避免关闭过程中还有新连接进来 if (m_pListen) { m_pListen-Close(); delete m_pListen; m_pListen NULL; } // 再逐个关闭已建立的连接 for (auto kv : g_connMap) { kv.second-Close(); // 先关句柄避免 OnClose 再回调进来 delete kv.second; } g_connMap.clear(); }逻辑说明先关监听再关连接顺序反了会有新连接在遍历过程中插入 map导致迭代器失效。Close()在delete之前调是因为 CAsyncSocket 的析构里也会调Close提前关掉可以保证析构时句柄已是无效值不会触发第二次关闭。这套顺序我用了很多年没再出现过退出时崩溃。4. 客户端的连接与收发OnConnect、OnReceive、OnSend 的正确打开方式客户端比服务端简单但坑更集中连接结果怎么判断、收到数据怎么读干净、发出去的数据怎么保证不丢。三个问题对应三个回调每个回调里都有一处「不这么写就会偶发失败」的细节。4.1 Create 与 Connect为什么 Connect 返回 SOCKET_ERROR 反而是好事客户端的Create一般传端口 0让系统分配本地端口类型SOCK_STREAM事件掩码至少要包含FD_CONNECT | FD_READ | FD_CLOSE。Create成功后调Connect(地址, 端口)注意这个函数在异步模式下几乎总是返回SOCKET_ERROR因为连接还没完成内核立刻返回WSAEWOULDBLOCK表示「正在连」。BOOL CMyClientSock::StartConnect(LPCTSTR lpszHost, UINT nPort) { if (!Create(0, SOCK_STREAM, FD_CONNECT | FD_READ | FD_CLOSE)) { TRACE(_T(Create failed, err%d\n), GetLastError()); return FALSE; } if (!Connect(lpszHost, nPort)) { int nErr GetLastError(); // WSAEWOULDBLOCK 表示连接正在进行这是正常路径不是失败 if (nErr ! WSAEWOULDBLOCK) { TRACE(_T(Connect failed immediately, err%d\n), nErr); Close(); return FALSE; } } return TRUE; }逻辑说明把WSAEWOULDBLOCK当成正常分支处理其他错误码才是真失败比如WSAEHOSTUNREACH、WSAECONNREFUSED。参数说明Connect的第一个参数可以直接传 IP 字符串也可以传主机名MFC 内部会做解析但解析是同步的如果主机名要走 DNS会阻塞 UI 线程几百毫秒内网场景建议直接写 IP。真正的连接结果在OnConnect里拿void CMyClientSock::OnConnect(int nErrorCode) { if (nErrorCode 0) { m_bConnected TRUE; // 连接成功后才能开始发数据 PostConnectReady(); } else { TRACE(_T(connect failed, err%d\n), nErrorCode); Close(); ScheduleReconnect(); } CAsyncSocket::OnConnect(nErrorCode); }注意OnConnect的参数本身就是错误码不需要再调GetLastError()。这一点和OnReceive不同容易记混。另外连接成功之前调用Send会失败GetLastError()返回WSAENOTCONN所以业务层要有一个「已连接」状态位发送前先判断。4.2 OnReceive 里的循环 recv 与 WSAEWOULDBLOCK 收尾OnReceive的语义是「接收缓冲区里现在有数据」不是「数据刚好是一条完整消息」。一次回调里可能来了半个包也可能来了三个包更可能的是你只读了一次缓冲区里还剩着而FD_READ不会因为你没读完就无限重发剩下的数据会一直躺在内核里直到下一次有新数据到达才可能再触发。所以OnReceive里必须循环读直到读空为止void CConnSock::OnReceive(int nErrorCode) { if (nErrorCode ! 0) { CAsyncSocket::OnReceive(nErrorCode); return; } char buf[4096]; for (;;) { int nRet Receive(buf, sizeof(buf), 0); if (nRet 0) { m_recvBuf.append(buf, nRet); // 先进累积缓冲区再做拆包 ParseFrames(); continue; } if (nRet 0) { // 对端正常关闭OnClose 随后也会来这里先收尾 Close(); break; } // nRet SOCKET_ERROR int nErr GetLastError(); if (nErr WSAEWOULDBLOCK) break; // 读干净了正常退出循环 if (nErr WSAECONNRESET) { Close(); break; } TRACE(_T(recv err%d\n), nErr); Close(); break; } CAsyncSocket::OnReceive(nErrorCode); }逻辑说明Receive返回大于 0 表示读到了字节继续循环返回 0 表示对端关了连接返回SOCKET_ERROR时要立刻取错误码WSAEWOULDBLOCK是正常结束信号其他才当异常处理。参数说明缓冲区给 4096 是折中太小会增加循环次数和系统调用开销太大会浪费栈空间一般OnReceive里用栈上 4K 到 8K 都合理。有一个细节要强调GetLastError()必须紧跟Receive调用中间不要插入任何其他 Winsock 函数因为错误码是线程局部的「最后一次错误」被别的调用一冲就变成别的值了。这类问题排查起来很痛苦日志里错误码和现象对不上就是因为取值时机不对。4.3 粘包不是玄学长度前缀协议与发送队列TCP 是字节流没有消息边界这一点在 CAsyncSocket 上表现得和原生 socket 完全一样跟异步不同步没关系。协议层要么用分隔符要么用长度前缀。内网二进制协议我一般用长度前缀4 字节大端包长 包体读的时候先判断累积缓冲区够不够 4 字节够了解析出包长再判断剩余长度够不够一个完整包够了就切出来交给业务不够就等着下次数据到达。void CConnSock::ParseFrames() { for (;;) { if (m_recvBuf.size() 4) return; // 连包头都没收全等下一次 // 4 字节大端包长网络字节序转主机字节序 uint32_t nBodyLen 0; const unsigned char* p (const unsigned char*)m_recvBuf.data(); nBodyLen (uint32_t(p[0]) 24) | (uint32_t(p[1]) 16) | (uint32_t(p[2]) 8) | uint32_t(p[3]); // 防御长度字段异常大说明流已经错位直接断开重建 if (nBodyLen 0 || nBodyLen 1024 * 1024) { Close(); return; } if (m_recvBuf.size() 4 nBodyLen) return; // 包体还没收全 std::string frame m_recvBuf.substr(4, nBodyLen); m_recvBuf.erase(0, 4 nBodyLen); DispatchFrame(frame); // 交给业务层 } }逻辑说明uint32_t(p[0]) 24这种写法避免了htonl在部分老编译器上的类型警告效果等价。nBodyLen的上限判断是必加的一旦流里出现脏数据长度字段可能是个几 GB 的随机值不拦住就会一直等一个永远不会来的包。参数说明1MB 上限是我的经验值如果你的业务有更大的包调大就行但要和发送端保持一致。发送端要维护一个队列。前面说过Send可能返回WSAEWOULDBLOCK此时剩余数据要挂在队列里等OnSend来了继续发而不是丢掉或者忙等。void CConnSock::QueueSend(const std::string payload) { uint32_t nLen (uint32_t)payload.size(); std::string packet; packet.push_back(char((nLen 24) 0xFF)); packet.push_back(char((nLen 16) 0xFF)); packet.push_back(char((nLen 8) 0xFF)); packet.push_back(char(nLen 0xFF)); packet payload; m_sendQueue.push_back(packet); FlushSend(); } void CConnSock::FlushSend() { while (!m_sendQueue.empty()) { const std::string front m_sendQueue.front(); int nSent Send(front.data(), (int)front.size(), 0); if (nSent SOCKET_ERROR) { int nErr GetLastError(); if (nErr WSAEWOULDBLOCK) return; // 等 OnSend 再来继续 Close(); return; } if (nSent (int)front.size()) { // 部分发送把剩下的留在队首 m_sendQueue.front() front.substr(nSent); return; } m_sendQueue.pop_front(); } } void CConnSock::OnSend(int nErrorCode) { if (nErrorCode 0) FlushSend(); CAsyncSocket::OnSend(nErrorCode); }逻辑说明所有业务数据先进队列FlushSend能发多少发多少遇到WSAEWOULDBLOCK就停等OnSend回调再续。参数说明m_sendQueue用std::deque还是std::list都行关键是别在遍历中删除导致迭代器失效上面用pop_front配合队首替换是安全的。5. 避坑排查五类让回调静默失败的典型翻车前面几章把正向流程走完了这一章专门写反面。CAsyncSocket 的失败模式很集中基本都能归到「对象生命周期」和「错误码取值」两类把这几条记住能省掉大量调试时间。5.1 生命周期类的三个坑现象一程序跑一段时间后随机崩溃调用栈指向 MFC 内部函数看不出自己代码的位置。原因在OnClose、OnReceive这些回调里直接delete this或delete了正在被回调的对象。回调返回后 MFC 还会访问该对象的成员访问的是已经释放的内存。 解决回调里只Close()把删除动作通过PostMessage投递到主线程延后执行或者把对象放进一个待删容器在OnIdle或定时器里统一清理。别用SendMessage同步投递那等于还是在回调栈里删。现象二客户端反复重连后服务端对新连接的OnReceive不再触发netstat里能看到连接 ESTABLISHED但就是没数据。原因OnAccept里new出来的对象在Accept失败时没有delete或者部分代码路径上Accept成功后没有把对象挂进连接表对象泄漏的同时原来的句柄可能被新连接复用导致事件分发到错误的空对象上。 解决Accept成败两条路径都要有明确归宿成功进表、失败立刻删。我习惯在new之后立刻加一行try-like 的守卫把「挂表」作为成功分支的唯一出口。现象三退出程序时偶尔弹「内存不能读」或者进程结束时任务管理器里句柄数不归零。原因StopAll里先遍历删连接、后关监听遍历过程中有新连接插入 map或者已经Close过的对象被delete两次。 解决先关监听、再遍历连接遍历时用「先收集指针再统一处理」的方式避免迭代器失效delete之前把指针置空退出时统一判空。5.2 数据与错误码类的两个坑现象四只有第一条业务数据发得出去后面全部石沉大海。原因把发送动作挂在OnSend里以为OnSend会周期性触发。实际上FD_WRITE是边沿触发连接成功时来一次之后只有缓冲区从满变空才会再来数据量小的时候第二次永远不会到。 解决Send直接调用只有返回WSAEWOULDBLOCK才把剩余数据挂队列并等待OnSendOnSend里做的是「续发队列」不是「开始发第一条」。现象五日志里错误码和实际现象对不上明明连接被拒绝打出来却是 0 或者 10035。原因Receive或Send返回错误后中间插入了TRACE、其他 Winsock 调用甚至另一个GetLastError把线程局部错误码覆盖了。 解决错误码取值必须紧跟失败调用第一行就存进局部变量之后再打日志。OnConnect、OnAccept、OnClose的参数本身就是错误码不要再去GetLastError()取一遍取到的可能是别的值。提示调试期可以给每个回调入口加一行带句柄和错误码的TRACE出问题时对照netstat -ano看连接状态比单步调试快得多。回调不触发时先确认消息泵在跑再确认事件掩码里包含了对应事件最后才怀疑业务代码。6. 进阶给 CAsyncSocket 加一层可测的心跳与重连异步 socket 最怕的是「假连接」TCP 层面还 ESTABLISHED对端进程其实已经卡死数据发出去没有任何回应而OnClose永远不来。生产环境里我一般加一层应用层心跳客户端每 5 秒发一个空包服务端收到就回客户端记录最后一次收到数据的时间超过 15 秒没动静就主动Close并进入重连流程。void CMyClientSock::OnTimer(UINT_PTR nID) { if (nID ! TIMER_HEARTBEAT || !m_bConnected) return; DWORD dwNow ::GetTickCount(); if (dwNow - m_dwLastRecvTick 15000) { // 超时判定为假连接主动断开交给重连逻辑 Close(); ScheduleReconnect(); return; } QueueSend(std::string()); // 空包作为心跳 }重连不要用固定间隔连接被拒绝时高频重试只会把日志刷满。我一般用 1 秒、2 秒、4 秒、8 秒的退避封顶 30 秒连接成功后重置计数。验证方式很简单把服务端进程直接杀掉看客户端日志里是否在 15 秒内断线、是否按退避节奏重连、服务端重新起来后能否自动恢复收发。这一步走通这个网络层才算真的能上现场。从那以后我每次接 CAsyncSocket 的活都会先写一个只有日志没有业务的空壳把连接、收发、断开、重连各跑一遍确认回调链路通了再往里塞协议。这份使用例子的价值也在这里它给的不是一段能跑的代码而是一条可以照着验证的路径。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/24 4:26:17 · 阅读 1.2k CAsyncSocket异步Socket实战：消息泵、粘包拆包与心跳重连
简介CAsyncSocket 使用例子面向具备一定 MFC 与 Windows 网络编程基础的开发者围绕异步套接字封装演示 TCP 客户端与服务端的完整通信流程。内容重点涉及套接字创建、连接与监听、Accept 接受新连接、Receive/Send 数据收发以及 OnConnect、OnAccept、OnReceive、OnSend、OnClose 等事件驱动处理并兼顾错误码检查、多客户端管理与文件分块传输思路。压缩包共 44 个文件以 11 个 h 头文件和 9 个 cpp 源文件为核心配有 ico、rc、dsp、dsw 等工程与资源文件及说明文本整体约 1.82MB便于直接打开工程对照学习。已有 445 人学习适合用作课程设计、网络通信实验或 MFC 异步 Socket 入门的参考范例可据此梳理客户端/服务端结构并理解事件回调与排错要点。1. 从「连上了但收不到数据」说起CAsyncSocket 到底替你做了什么上个月有个做工业上位机的同行拿来一段 MFC 老代码CAsyncSocket 的客户端和服务端都 Create 成功了Connect 也返回了界面上却一条数据都不刷新日志里连 OnReceive 的影子都没有。他以为是协议写错查了两天最后发现 socket 建在了工作线程里那个线程压根没跑消息循环。这份 CAsyncSocket 使用例子最容易被忽略的一点就是它本质上是 WSAAsyncSelect 的一层薄封装——OnAccept、OnConnect、OnReceive、OnSend、OnClose 全部是窗口消息的回调没有消息泵就没有一切。这份资源把服务端监听、客户端连接、收发拆包、断线清理这条链路串成可直接抄的结构适合正在维护 MFC 老项目、又不想把整个网络层推倒重写的开发者。2. 事件驱动的地基WSAAsyncSelect、消息泵与三个初始化细节在写下第一行Create之前得先接受一个事实CAsyncSocket 不是「调用一个函数就完事」的同步 socket它是把 WinSock 的异步事件翻译成窗口消息再由 MFC 分发到你的虚函数上。这条链路里任何一环断掉表现出来的都是「代码没错就是不回调」比崩溃更难查。所以这一章先把地基打牢再谈业务。2.1 AfxSocketInit 与消息泵异步回调靠谁来敲门MFC 里所有 socket 操作之前必须调用一次AfxSocketInit它内部完成WSAStartup并把 Winsock 版本协商好。位置很讲究放在CWinApp::InitInstance的最前面比任何窗口、任何 CAsyncSocket 成员对象都早。因为全局或成员对象的构造可能早于InitInstance一旦在AfxSocketInit之前就Create拿到的是WSANOTINITIALISED而且这个错误码经常被忽略掉。BOOL CMyApp::InitInstance() { // 必须在任何 CAsyncSocket 对象创建之前调用内部完成 WSAStartup if (!AfxSocketInit()) { AfxMessageBox(_T(Winsock 初始化失败)); return FALSE; } CWinApp::InitInstance(); // 之后再创建主窗口、再 new 出服务端 socket return TRUE; }AfxSocketInit的参数是一个可选的WSADATA*一般传 NULL 就行返回 FALSE 表示 Winsock 环境没起来此时继续往下走只会得到一串莫名其妙的错误码。真正让新手翻车的是第二个细节MFC 在内部创建了一个隐藏窗口来接收FD_*消息再由它分发给对应的 CAsyncSocket 对象。这个隐藏窗口是线程局部的消息必须被该线程的消息循环取出来并DispatchMessage回调才会发生。主 UI 线程天然有CWinApp::Run在泵消息所以主线程里写例子一切正常一旦你为了「不卡界面」把 socket 挪到AfxBeginThread开出来的工作线程就变成另一回事了。UINT CNetWorker::Run() { // 每个使用 socket 的线程都要独立初始化一次 Winsock 环境 if (!AfxSocketInit()) return 1; CMyClientSock sock; if (!sock.Create()) return 1; sock.Connect(_T(127.0.0.1), 9000); // 关键线程必须自己泵消息否则 OnConnect/OnReceive 永远不会被调用 MSG msg; while (::GetMessage(msg, NULL, 0, 0)) { ::TranslateMessage(msg); ::DispatchMessage(msg); } return 0; }逻辑说明AfxSocketInit在每个线程里都要调一次MFC 的模块状态是线程局部的主线程初始化过不代表工作线程也初始化了。参数说明GetMessage的第二个参数传 NULL 表示取本线程所有窗口消息包括那个隐藏 socket 窗口的消息如果传了某个窗口句柄socket 消息就取不到。另一个隐蔽点循环里如果有Sleep、WaitForSingleObject卡住很久回调也会跟着延迟表现成「偶尔丢包」其实是你自己把消息泵堵住了。2.2 事件掩码怎么选FD_READ、FD_WRITE、FD_ACCEPT、FD_CLOSE 的触发时机Create的第三个参数lEvent是事件掩码默认值包含 READ、WRITE、OOB、ACCEPT、CONNECT、CLOSE 六个。默认值能跑但对客户端来说 ACCEPT 永远用不上对监听套接字来说 READ/WRITE 又没意义掩码开得越精确内核里做的判断越少出问题的面也越小。更重要的是要搞清楚每个事件是「电平触发」还是「边沿触发」这直接决定了你的事件处理函数里该写什么。事件触发时机是否边沿触发常见误用FD_READ接收缓冲区有数据可读否未读完会再次触发只 recv 一次就返回剩余数据留在缓冲区FD_WRITE连接建立成功或发送缓冲区由满变空是把每个数据包都挂到 OnSend 上再发FD_ACCEPT有新的待处理连接否不在 OnAccept 里循环 AcceptFD_CONNECT连接完成成功或失败是只来一次不看错误码就当作连接成功FD_CLOSE对端发送 FIN 关闭是在 OnClose 里直接 delete thisFD_WRITE的边沿触发是最多人栽跟头的地方。它的语义不是「你随时可以发」而是「发送缓冲区从不可写变成可写」。连接成功后它会来一次之后只有在某次Send返回WSAEWOULDBLOCK、缓冲区被排空之后它才会再来。如果你的代码从不超过缓冲区上限那OnSend一辈子只触发一次把业务数据挂在OnSend里发的写法必然只发出第一条。FD_CONNECT同样需要看错误码。很多人以为OnConnect被调用就是连上了实际上连接被拒绝、超时、主机不可达都会走到这里区别只在GetLastError()的返回值成功时是 0。2.3 一个能跑通的最小服务端骨架把地基铺好后先写一个最小服务端把链路验证通再往里塞业务。下面这段是我常用的起点监听套接字一个连接套接字按需 new事件处理只打日志先确认回调能进来。class CListenSock : public CAsyncSocket { public: virtual void OnAccept(int nErrorCode) { if (nErrorCode ! 0) { CAsyncSocket::OnAccept(nErrorCode); return; } // 每个连接都必须 new 一个新的 CAsyncSocket 派生对象来承接 CConnSock* pConn new CConnSock(); if (!Accept(*pConn)) { // Accept 失败要立刻回收否则是稳定的内存泄漏 delete pConn; } else { g_connMap[pConn-m_hSocket] pConn; // 交给连接表托管 TRACE(_T(accept fd%d\n), pConn-m_hSocket); } CAsyncSocket::OnAccept(nErrorCode); } }; BOOL CServerApp::StartListen(UINT nPort) { m_pListen new CListenSock(); // 第三参数只开 ACCEPT 和 CLOSE监听套接字不碰收发 if (!m_pListen-Create(nPort, SOCK_STREAM, FD_ACCEPT | FD_CLOSE)) { TRACE(_T(Create failed, err%d\n), m_pListen-GetLastError()); return FALSE; } if (!m_pListen-Listen(5)) { TRACE(_T(Listen failed, err%d\n), m_pListen-GetLastError()); return FALSE; } return TRUE; }逻辑说明监听套接字只负责FD_ACCEPT每次回调里new一个连接对象并调用Accept把它「接」过来接好之后这个新对象就拥有了独立的 socket 句柄和独立的事件。参数说明Create的第一个参数是端口传 0 表示由系统分配客户端一般传 0第二个参数SOCK_STREAM就是 TCPListen的参数是 backlog传 5 在老代码里很常见现代机器上可以给到 32 或 64但对内网几十个连接的上位机场景差别不大。这里要提醒一点Accept的第一个参数是引用接收方对象必须已经构造出来MFC 内部会把这个新连接句柄Attach到它身上并注册事件掩码。如果你在OnAccept里复用了监听对象本身第一次能连上第二次就会因为句柄被覆盖而整个服务端失聪。3. 服务端 accept 的完整链路监听套接字与连接对象怎么分开管理服务端最容易写错的地方不在 accept 本身而在于「谁拥有谁、谁负责删谁」。监听套接字活在很长的时间里连接套接字活在一次会话里两者的生命周期完全不同混在一起写就会出重复析构、野指针、句柄泄漏。3.1 Create、Listen、OnAccept 三步的参数含义Create在内部已经完成了socket和bind两步所以你会看到有的教程在Create前面还手动bind一次那是CSocket或原生 API 的写法直接套到 CAsyncSocket 上会bind两次失败。Create的第四个参数是绑定地址默认 NULL即绑定所有本地网卡如果机器有多张网卡、只想在指定网段监听就填上具体 IP。Listen只对监听套接字有效对已经Accept出来的连接对象调用是没意义的。backlog 参数的含义是已完成三次握手但还没被 accept 的队列长度超过这个长度之后新连接会被内核直接忽略或拒绝表现出来是客户端偶发连接超时。老代码里写 5 意味着并发握手高峰只有 5 个排队位压力大时会明显漏连。OnAccept的nErrorCode参数一定要先判断。这个回调在出错时也会被调用比如监听套接字被意外关闭此时Accept必然失败如果不看错误码直接往下走new出来的对象会被立刻删掉日志里刷一片无意义的 accept 失败。3.2 在 OnAccept 里 new 一个对象以及它的销毁时机连接对象的销毁是整个服务端最需要小心的一处。有三种情况会导致连接结束对端正常关闭OnClose、本端主动关闭业务决定踢人、发生错误OnClose带非零错误码。这三条路最后都要汇到同一个动作从连接表里摘掉、Close、然后delete。但delete的时机不能放在回调函数内部。原因很直接OnClose返回之后MFC 的分发代码还要访问这个对象的成员比如判断句柄是否还有效你在这里把this删了后续访问就是野指针。血泪经验是别指望调试器能帮你定位这种崩溃的调用栈往往指向 MFC 内部看起来跟你写的代码毫无关系。我一般的做法是回调里只做Close()和「打标记」真正的删除交给主线程消息。// 自定义消息主窗口收到后再做实际删除 #define WM_SOCK_DELETE (WM_USER 100) void CConnSock::OnClose(int nErrorCode) { if (g_connMap.count(m_hSocket)) g_connMap.erase(m_hSocket); // 只关闭句柄不 delete 自己 Close(); // 把自己交给主线程延后删除避免在 MFC 分发过程中析构 if (g_pMainWnd) g_pMainWnd-PostMessage(WM_SOCK_DELETE, (WPARAM)this, 0); CAsyncSocket::OnClose(nErrorCode); } // 主窗口的消息处理 LRESULT CMainWnd::OnSockDelete(WPARAM wParam, LPARAM) { CConnSock* p reinterpret_castCConnSock*(wParam); delete p; // 到这一步MFC 的这次分发早就返回了 return 0; }逻辑说明Close()会关闭句柄并把内部句柄置为无效对象本身还活着可以安全地继续访问成员。PostMessage是异步投递等消息被处理时OnClose的调用栈早已退出。参数说明WM_SOCK_DELETE用WM_USER 100只是习惯只要不和已有自定义消息冲突就行wParam存指针在 32 位程序里没问题64 位程序里指针是 8 字节WPARAM也是 8 字节同样安全。3.3 连接表管理把 socket 指针映射到业务上下文服务端不可能只有一个连接必须有一张表把句柄或对象指针映射到业务状态。常见做法是用std::mapSOCKET, CConnSock*或CMapSOCKET, SOCKET, CConnSock*, CConnSock*。key 用m_hSocket而不是对象地址因为对象地址在new之后虽然稳定但用句柄查找更符合直觉而且日志里打句柄也方便对照netstat。连接表要处理三个动作accept 时插入、close 时摘除、程序退出时遍历关闭。程序退出这一步特别容易漏很多人只delete监听对象连接对象全部泄漏进程结束时操作系统会回收句柄所以平时看不出来一旦你的程序作为服务常驻、又支持热重启泄漏就会累积。void CServerApp::StopAll() { // 先停监听避免关闭过程中还有新连接进来 if (m_pListen) { m_pListen-Close(); delete m_pListen; m_pListen NULL; } // 再逐个关闭已建立的连接 for (auto kv : g_connMap) { kv.second-Close(); // 先关句柄避免 OnClose 再回调进来 delete kv.second; } g_connMap.clear(); }逻辑说明先关监听再关连接顺序反了会有新连接在遍历过程中插入 map导致迭代器失效。Close()在delete之前调是因为 CAsyncSocket 的析构里也会调Close提前关掉可以保证析构时句柄已是无效值不会触发第二次关闭。这套顺序我用了很多年没再出现过退出时崩溃。4. 客户端的连接与收发OnConnect、OnReceive、OnSend 的正确打开方式客户端比服务端简单但坑更集中连接结果怎么判断、收到数据怎么读干净、发出去的数据怎么保证不丢。三个问题对应三个回调每个回调里都有一处「不这么写就会偶发失败」的细节。4.1 Create 与 Connect为什么 Connect 返回 SOCKET_ERROR 反而是好事客户端的Create一般传端口 0让系统分配本地端口类型SOCK_STREAM事件掩码至少要包含FD_CONNECT | FD_READ | FD_CLOSE。Create成功后调Connect(地址, 端口)注意这个函数在异步模式下几乎总是返回SOCKET_ERROR因为连接还没完成内核立刻返回WSAEWOULDBLOCK表示「正在连」。BOOL CMyClientSock::StartConnect(LPCTSTR lpszHost, UINT nPort) { if (!Create(0, SOCK_STREAM, FD_CONNECT | FD_READ | FD_CLOSE)) { TRACE(_T(Create failed, err%d\n), GetLastError()); return FALSE; } if (!Connect(lpszHost, nPort)) { int nErr GetLastError(); // WSAEWOULDBLOCK 表示连接正在进行这是正常路径不是失败 if (nErr ! WSAEWOULDBLOCK) { TRACE(_T(Connect failed immediately, err%d\n), nErr); Close(); return FALSE; } } return TRUE; }逻辑说明把WSAEWOULDBLOCK当成正常分支处理其他错误码才是真失败比如WSAEHOSTUNREACH、WSAECONNREFUSED。参数说明Connect的第一个参数可以直接传 IP 字符串也可以传主机名MFC 内部会做解析但解析是同步的如果主机名要走 DNS会阻塞 UI 线程几百毫秒内网场景建议直接写 IP。真正的连接结果在OnConnect里拿void CMyClientSock::OnConnect(int nErrorCode) { if (nErrorCode 0) { m_bConnected TRUE; // 连接成功后才能开始发数据 PostConnectReady(); } else { TRACE(_T(connect failed, err%d\n), nErrorCode); Close(); ScheduleReconnect(); } CAsyncSocket::OnConnect(nErrorCode); }注意OnConnect的参数本身就是错误码不需要再调GetLastError()。这一点和OnReceive不同容易记混。另外连接成功之前调用Send会失败GetLastError()返回WSAENOTCONN所以业务层要有一个「已连接」状态位发送前先判断。4.2 OnReceive 里的循环 recv 与 WSAEWOULDBLOCK 收尾OnReceive的语义是「接收缓冲区里现在有数据」不是「数据刚好是一条完整消息」。一次回调里可能来了半个包也可能来了三个包更可能的是你只读了一次缓冲区里还剩着而FD_READ不会因为你没读完就无限重发剩下的数据会一直躺在内核里直到下一次有新数据到达才可能再触发。所以OnReceive里必须循环读直到读空为止void CConnSock::OnReceive(int nErrorCode) { if (nErrorCode ! 0) { CAsyncSocket::OnReceive(nErrorCode); return; } char buf[4096]; for (;;) { int nRet Receive(buf, sizeof(buf), 0); if (nRet 0) { m_recvBuf.append(buf, nRet); // 先进累积缓冲区再做拆包 ParseFrames(); continue; } if (nRet 0) { // 对端正常关闭OnClose 随后也会来这里先收尾 Close(); break; } // nRet SOCKET_ERROR int nErr GetLastError(); if (nErr WSAEWOULDBLOCK) break; // 读干净了正常退出循环 if (nErr WSAECONNRESET) { Close(); break; } TRACE(_T(recv err%d\n), nErr); Close(); break; } CAsyncSocket::OnReceive(nErrorCode); }逻辑说明Receive返回大于 0 表示读到了字节继续循环返回 0 表示对端关了连接返回SOCKET_ERROR时要立刻取错误码WSAEWOULDBLOCK是正常结束信号其他才当异常处理。参数说明缓冲区给 4096 是折中太小会增加循环次数和系统调用开销太大会浪费栈空间一般OnReceive里用栈上 4K 到 8K 都合理。有一个细节要强调GetLastError()必须紧跟Receive调用中间不要插入任何其他 Winsock 函数因为错误码是线程局部的「最后一次错误」被别的调用一冲就变成别的值了。这类问题排查起来很痛苦日志里错误码和现象对不上就是因为取值时机不对。4.3 粘包不是玄学长度前缀协议与发送队列TCP 是字节流没有消息边界这一点在 CAsyncSocket 上表现得和原生 socket 完全一样跟异步不同步没关系。协议层要么用分隔符要么用长度前缀。内网二进制协议我一般用长度前缀4 字节大端包长 包体读的时候先判断累积缓冲区够不够 4 字节够了解析出包长再判断剩余长度够不够一个完整包够了就切出来交给业务不够就等着下次数据到达。void CConnSock::ParseFrames() { for (;;) { if (m_recvBuf.size() 4) return; // 连包头都没收全等下一次 // 4 字节大端包长网络字节序转主机字节序 uint32_t nBodyLen 0; const unsigned char* p (const unsigned char*)m_recvBuf.data(); nBodyLen (uint32_t(p[0]) 24) | (uint32_t(p[1]) 16) | (uint32_t(p[2]) 8) | uint32_t(p[3]); // 防御长度字段异常大说明流已经错位直接断开重建 if (nBodyLen 0 || nBodyLen 1024 * 1024) { Close(); return; } if (m_recvBuf.size() 4 nBodyLen) return; // 包体还没收全 std::string frame m_recvBuf.substr(4, nBodyLen); m_recvBuf.erase(0, 4 nBodyLen); DispatchFrame(frame); // 交给业务层 } }逻辑说明uint32_t(p[0]) 24这种写法避免了htonl在部分老编译器上的类型警告效果等价。nBodyLen的上限判断是必加的一旦流里出现脏数据长度字段可能是个几 GB 的随机值不拦住就会一直等一个永远不会来的包。参数说明1MB 上限是我的经验值如果你的业务有更大的包调大就行但要和发送端保持一致。发送端要维护一个队列。前面说过Send可能返回WSAEWOULDBLOCK此时剩余数据要挂在队列里等OnSend来了继续发而不是丢掉或者忙等。void CConnSock::QueueSend(const std::string payload) { uint32_t nLen (uint32_t)payload.size(); std::string packet; packet.push_back(char((nLen 24) 0xFF)); packet.push_back(char((nLen 16) 0xFF)); packet.push_back(char((nLen 8) 0xFF)); packet.push_back(char(nLen 0xFF)); packet payload; m_sendQueue.push_back(packet); FlushSend(); } void CConnSock::FlushSend() { while (!m_sendQueue.empty()) { const std::string front m_sendQueue.front(); int nSent Send(front.data(), (int)front.size(), 0); if (nSent SOCKET_ERROR) { int nErr GetLastError(); if (nErr WSAEWOULDBLOCK) return; // 等 OnSend 再来继续 Close(); return; } if (nSent (int)front.size()) { // 部分发送把剩下的留在队首 m_sendQueue.front() front.substr(nSent); return; } m_sendQueue.pop_front(); } } void CConnSock::OnSend(int nErrorCode) { if (nErrorCode 0) FlushSend(); CAsyncSocket::OnSend(nErrorCode); }逻辑说明所有业务数据先进队列FlushSend能发多少发多少遇到WSAEWOULDBLOCK就停等OnSend回调再续。参数说明m_sendQueue用std::deque还是std::list都行关键是别在遍历中删除导致迭代器失效上面用pop_front配合队首替换是安全的。5. 避坑排查五类让回调静默失败的典型翻车前面几章把正向流程走完了这一章专门写反面。CAsyncSocket 的失败模式很集中基本都能归到「对象生命周期」和「错误码取值」两类把这几条记住能省掉大量调试时间。5.1 生命周期类的三个坑现象一程序跑一段时间后随机崩溃调用栈指向 MFC 内部函数看不出自己代码的位置。原因在OnClose、OnReceive这些回调里直接delete this或delete了正在被回调的对象。回调返回后 MFC 还会访问该对象的成员访问的是已经释放的内存。 解决回调里只Close()把删除动作通过PostMessage投递到主线程延后执行或者把对象放进一个待删容器在OnIdle或定时器里统一清理。别用SendMessage同步投递那等于还是在回调栈里删。现象二客户端反复重连后服务端对新连接的OnReceive不再触发netstat里能看到连接 ESTABLISHED但就是没数据。原因OnAccept里new出来的对象在Accept失败时没有delete或者部分代码路径上Accept成功后没有把对象挂进连接表对象泄漏的同时原来的句柄可能被新连接复用导致事件分发到错误的空对象上。 解决Accept成败两条路径都要有明确归宿成功进表、失败立刻删。我习惯在new之后立刻加一行try-like 的守卫把「挂表」作为成功分支的唯一出口。现象三退出程序时偶尔弹「内存不能读」或者进程结束时任务管理器里句柄数不归零。原因StopAll里先遍历删连接、后关监听遍历过程中有新连接插入 map或者已经Close过的对象被delete两次。 解决先关监听、再遍历连接遍历时用「先收集指针再统一处理」的方式避免迭代器失效delete之前把指针置空退出时统一判空。5.2 数据与错误码类的两个坑现象四只有第一条业务数据发得出去后面全部石沉大海。原因把发送动作挂在OnSend里以为OnSend会周期性触发。实际上FD_WRITE是边沿触发连接成功时来一次之后只有缓冲区从满变空才会再来数据量小的时候第二次永远不会到。 解决Send直接调用只有返回WSAEWOULDBLOCK才把剩余数据挂队列并等待OnSendOnSend里做的是「续发队列」不是「开始发第一条」。现象五日志里错误码和实际现象对不上明明连接被拒绝打出来却是 0 或者 10035。原因Receive或Send返回错误后中间插入了TRACE、其他 Winsock 调用甚至另一个GetLastError把线程局部错误码覆盖了。 解决错误码取值必须紧跟失败调用第一行就存进局部变量之后再打日志。OnConnect、OnAccept、OnClose的参数本身就是错误码不要再去GetLastError()取一遍取到的可能是别的值。提示调试期可以给每个回调入口加一行带句柄和错误码的TRACE出问题时对照netstat -ano看连接状态比单步调试快得多。回调不触发时先确认消息泵在跑再确认事件掩码里包含了对应事件最后才怀疑业务代码。6. 进阶给 CAsyncSocket 加一层可测的心跳与重连异步 socket 最怕的是「假连接」TCP 层面还 ESTABLISHED对端进程其实已经卡死数据发出去没有任何回应而OnClose永远不来。生产环境里我一般加一层应用层心跳客户端每 5 秒发一个空包服务端收到就回客户端记录最后一次收到数据的时间超过 15 秒没动静就主动Close并进入重连流程。void CMyClientSock::OnTimer(UINT_PTR nID) { if (nID ! TIMER_HEARTBEAT || !m_bConnected) return; DWORD dwNow ::GetTickCount(); if (dwNow - m_dwLastRecvTick 15000) { // 超时判定为假连接主动断开交给重连逻辑 Close(); ScheduleReconnect(); return; } QueueSend(std::string()); // 空包作为心跳 }重连不要用固定间隔连接被拒绝时高频重试只会把日志刷满。我一般用 1 秒、2 秒、4 秒、8 秒的退避封顶 30 秒连接成功后重置计数。验证方式很简单把服务端进程直接杀掉看客户端日志里是否在 15 秒内断线、是否按退避节奏重连、服务端重新起来后能否自动恢复收发。这一步走通这个网络层才算真的能上现场。从那以后我每次接 CAsyncSocket 的活都会先写一个只有日志没有业务的空壳把连接、收发、断开、重连各跑一遍确认回调链路通了再往里塞协议。这份使用例子的价值也在这里它给的不是一段能跑的代码而是一条可以照着验证的路径。希望帮到你。本文还有配套的精品资源点击获取