简介：面向Windows CE嵌入式网络开发者的TCP通信示例工程，适合希望在VS2005环境下理解Winsock编程的初中级开发者，用于解决WinCE设备端套接字创建、连接建立与数据收发等实践问题。压缩包共29个文件，以C++源码与头文件、vcproj工程配置、rc资源脚本、manifest及可执行文件为主，另有调试与解决方案相关文件，整体约4.45MB，可直接导入VS2005查看工程结构。目前已有315人学习下载。样例围绕客户端与服务器通信展开，涵盖socket、connect、send、recv及closesocket等关键调用，并涉及ws2_32.lib链接与_WIN32_WCE预处理配置，能帮助读者对照源码梳理连接建立、数据收发与异常关闭的完整流程。工程规模精简，适合作为WinCE网络应用入门参照，也可在调试中观察连接与收发过程，理解错误处理和资源释放方式，对套接字生命周期形成直观认识，并迁移到自有嵌入式项目。
1. WinCE TCP通信不是“能连上”就完事：先看最小闭环
很多人在 WinCE 上第一次写 TCP 通信，现象都差不多：服务端能 accept，客户端也能 connect，短测正常，跑十几分钟就卡在 recv，重启进程又恢复。问题通常不在 socket API 本身，而在 Winsock 初始化、超时设置、线程退出和断线判断没有配对。围绕 WinCE TCP 通信整理的这套示例工程，重点不是演示一个 connect，而是把服务端/客户端最小闭环、阻塞与 select 的超时、粘包边界和重连排查拆开。适合正在维护嵌入式设备网络模块的开发者，也适合刚接手老工程、需要把“能连”变成“能长期跑”的现场人员。下面按可编译顺序推进，先跑通再谈稳定。
2. 从WSAStartup到sockaddr_in：WinCE下TCP通信的最小闭环
WinCE 下的 TCP 通信绕不开 Winsock。桌面 Windows 上很多默认行为，在嵌入式 SDK 和不同 BSP 上会有裁剪差异，所以第一步不是写业务，而是把版本协商、socket 创建、地址填写和错误码检查做成一个能重复跑的冒烟测试。这里有个血泪经验：不要在一个工程里到处散落 WSAStartup，初始化和清理最好收口到两个函数，后面查资源泄漏会轻松很多。
2.1 WSAStartup版本协商与socket创建
Winsock 使用前必须调用 WSAStartup，参数里请求版本，调用成功后 WSADATA 里带回实际协商版本。常见做法是先请求 2.2，失败后降级到 1.1 再试；具体支持到哪一版，看工程所用 SDK 的头文件和库，不要默认桌面环境的行为完全一致。下面的写法把初始化和 socket 创建拆开，失败路径都返回明确错误。
#include <winsock.h> // 工程设置里把 Winsock 库加入链接项，不要只依赖某一行 pragma bool InitWinsock() { WSADATA wsa; WORD ver = MAKEWORD(2, 2); int ret = WSAStartup(ver, &wsa); if (ret != 0) { // 部分嵌入式 SDK 只稳定支持 1.1，降级再试一次 ver = MAKEWORD(1, 1); ret = WSAStartup(ver, &wsa); } if (ret != 0) { return false; } // 协商版本不符合预期时，按失败处理并清理 if (LOBYTE(wsa.wVersion) != 2 && LOBYTE(wsa.wVersion) != 1) { WSACleanup(); return false; } return true; } SOCKET CreateTcpSocket() { SOCKET s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (s == INVALID_SOCKET) { return INVALID_SOCKET; } return s; }MAKEWORD(2,2)表示请求的主次版本，降级逻辑是为了兼容老 SDK；WSADATA不要只声明不检查，协商结果不对时继续往下走，后面会出现一些很难定位的玄学错误。AF_INET指定 IPv4，SOCK_STREAM指定面向连接的字节流，IPPROTO_TCP明确协议。INVALID_SOCKET必须判断，不能拿-1或NULL代替。WSAStartup 建议在进程启动、创建业务线程之前调用一次，WSACleanup 在所有 socket 关闭之后调用，二者要配对。
2.2 地址结构、字节序与端口复用
服务端 bind 之前要填sockaddr_in，端口必须用htons转网络序，地址用htonl(INADDR_ANY)表示监听本机所有网卡。客户端填目标 IP 时，老工程常见inet_addr，它返回值要判断INADDR_NONE。不少人在 WinCE 上直接给sin_port赋主机序端口，短测能过，换端口或跨设备就翻车，原因是大小端没有统一。
bool BindServer(SOCKET s, unsigned short port) { sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(port); // 端口转网络序 addr.sin_addr.s_addr = htonl(INADDR_ANY); // 监听所有网卡 int opt = 1; // 重连频繁时减少 TIME_WAIT 带来的 bind 失败，但不要把它当成万能药 setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&opt, sizeof(opt)); return bind(s, (sockaddr*)&addr, sizeof(addr)) == 0; } bool FillServerAddr(sockaddr_in& addr, const char* ip, unsigned short port) { memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = inet_addr(ip); if (addr.sin_addr.s_addr == INADDR_NONE) { return false; // IP 字符串非法 } return true; }SO_REUSEADDR在 WinCE 不同 SDK 上的行为不完全一样，设置失败不影响主流程，但 bind 失败时必须看WSAGetLastError()。bind的第三个参数是结构体长度，不要传成指针大小。inet_addr只适合 IPv4 点分十进制，返回INADDR_NONE既可能是非法 IP，也可能是广播地址，工程里要结合场景判断。地址结构使用前统一memset，避免栈上残留值导致偶发连接失败。
2.3 一次可复现的connect/bind冒烟测试
最小闭环建议先不接业务：服务端 bind、listen、accept；客户端 socket、connect；两端各发一段固定字符串再关闭。这样能把初始化、地址、端口、防火墙和路由问题一次排掉。下面只保留关键路径，错误分支都打印错误码，现场排查时错误码比“连不上”有用得多。
bool TcpSmokeServer(unsigned short port) { SOCKET listenSock = CreateTcpSocket(); if (listenSock == INVALID_SOCKET) return false; if (!BindServer(listenSock, port)) { closesocket(listenSock); return false; } if (listen(listenSock, 5) != 0) { // backlog 按业务并发量调整 closesocket(listenSock); return false; } sockaddr_in peer; int peerLen = sizeof(peer); SOCKET client = accept(listenSock, (sockaddr*)&peer, &peerLen); if (client == INVALID_SOCKET) { closesocket(listenSock); return false; } const char* msg = "hello-wince"; send(client, msg, (int)strlen(msg), 0); closesocket(client); closesocket(listenSock); return true; } bool TcpSmokeClient(const char* ip, unsigned short port) { SOCKET s = CreateTcpSocket(); if (s == INVALID_SOCKET) return false; sockaddr_in addr; if (!FillServerAddr(addr, ip, port)) { closesocket(s); return false; } if (connect(s, (sockaddr*)&addr, sizeof(addr)) != 0) { closesocket(s); return false; } char buf[64] = {0}; int n = recv(s, buf, sizeof(buf) - 1, 0); closesocket(s); return n > 0; }listen的 backlog 不是越大越好，嵌入式设备内存有限，按实际并发连接数给，常见 3 到 10 够用。accept的peerLen必须初始化为结构体大小，accept 成功后返回的是新连接句柄，监听句柄还要继续保留。冒烟测试里send和recv只做一次，真实业务不能假设一次调用就发完或收完，这一点在第 3 章展开。测试顺序建议先本机回环，再同网段，再跨路由，每换一层只改一个变量。
3. 服务端与客户端双端落地：accept/connect到send/recv的线程边界
最小闭环跑通后，下一步是把服务端和客户端写成能长期运行的骨架。WinCE 设备常见资源约束是内存小、线程栈有限、网络可能随时断开，所以服务端不能 accept 之后就在主循环里同步处理，客户端也不能 connect 之后无限阻塞收数据。这一章把监听、连接、收发和线程退出拆开，代码按可替换业务解析的方式组织。
3.1 服务端监听、accept循环与连接句柄管理
服务端主循环只负责 accept，把新连接交给工作线程，工作线程退出时负责关闭自己的 socket。这里最容易出的问题是主线程和工作线程同时 closesocket，或者 accept 失败后直接 break，导致服务端悄悄退出。下面用一个运行标志和线程入口把边界写清楚，实际工程可以把HandleClient换成你的协议解析。
volatile bool g_serverRunning = true; void HandleClient(SOCKET client) { char buf[512]; while (g_serverRunning) { int n = recv(client, buf, sizeof(buf), 0); if (n <= 0) { break; // 0 表示对端关闭，SOCKET_ERROR 看错误码 } // 这里只做回声，真实业务不要在线程里做长耗时解析 send(client, buf, n, 0); } } DWORD WINAPI ClientThread(LPVOID ctx) { SOCKET client = (SOCKET)(int)ctx; // WinCE 32 位工程常见转换方式 HandleClient(client); closesocket(client); // 谁持有谁关闭，避免主线程重复关 return 0; } bool StartTcpServer(unsigned short port) { SOCKET listenSock = CreateTcpSocket(); if (listenSock == INVALID_SOCKET) return false; if (!BindServer(listenSock, port)) { closesocket(listenSock); return false; } if (listen(listenSock, 5) != 0) { closesocket(listenSock); return false; } while (g_serverRunning) { sockaddr_in peer; int peerLen = sizeof(peer); SOCKET client = accept(listenSock, (sockaddr*)&peer, &peerLen); if (client == INVALID_SOCKET) { // 运行标志被置 false 时 accept 可能被打断，按退出处理 if (!g_serverRunning) break; continue; } HANDLE th = CreateThread(NULL, 0, ClientThread, (LPVOID)(int)client, 0, NULL); if (th == NULL) { closesocket(client); // 线程没创建成功，主线程负责关 } else { CloseHandle(th); // 不等待时及时关闭线程句柄 } } closesocket(listenSock); return true; }accept返回INVALID_SOCKET不一定是致命错误，先看运行标志和WSAGetLastError()，不要无脑 break。工作线程拿到 socket 后自己关闭，主线程只在创建线程失败时关闭，否则容易出现双重关闭。CreateThread返回的线程句柄不用时要CloseHandle，这和 socket 句柄是两套资源。线程栈大小按业务调整，嵌入式设备不要默认给太大，也不能小到解析函数一深就溢出。
3.2 客户端连接超时与重试的写法
阻塞 connect 在链路异常时可能等很久，现场表现是界面无响应或重连线程卡死。常见做法是把 socket 临时设为非阻塞，connect 返回WSAEWOULDBLOCK后用 select 等写事件，再通过SO_ERROR取真实连接结果。连接完成后恢复阻塞模式，后续收发按你的模型决定。
bool ConnectWithTimeout(SOCKET s, const char* ip, unsigned short port, int timeoutMs) { sockaddr_in addr; if (!FillServerAddr(addr, ip, port)) return false; unsigned long nonBlock = 1; ioctlsocket(s, FIONBIO, &nonBlock); // 临时非阻塞 int ret = connect(s, (sockaddr*)&addr, sizeof(addr)); if (ret == SOCKET_ERROR) { int err = WSAGetLastError(); if (err != WSAEWOULDBLOCK) { nonBlock = 0; ioctlsocket(s, FIONBIO, &nonBlock); return false; } fd_set wset; FD_ZERO(&wset); FD_SET(s, &wset); timeval tv; tv.tv_sec = timeoutMs / 1000; tv.tv_usec = (timeoutMs % 1000) * 1000; ret = select(0, NULL, &wset, NULL, &tv); if (ret <= 0) { // 0 超时，<0 错误 nonBlock = 0; ioctlsocket(s, FIONBIO, &nonBlock); return false; } int soError = 0; int optLen = sizeof(soError); getsockopt(s, SOL_SOCKET, SO_ERROR, (char*)&soError, &optLen); if (soError != 0) { nonBlock = 0; ioctlsocket(s, FIONBIO, &nonBlock); return false; } } nonBlock = 0; ioctlsocket(s, FIONBIO, &nonBlock); // 恢复阻塞，按后续模型决定 return true; }ioctlsocket的FIONBIO参数是unsigned long*，不是布尔值指针。select第一个参数在 WinCE 上通常忽略，但不要因此乱传；写集合表示等待可写，连接成功或失败都会让写集合就绪。SO_ERROR取到 0 才算真正连上，不能只看 select 返回值。超时后必须恢复阻塞模式或关闭 socket，否则这个句柄后续行为会和预期不一致。重试不要紧循环，常见做法是 1 秒、2 秒、4 秒退避，设上限。
3.3 收发循环：处理部分发送、部分接收和长度前缀
TCP 是字节流，没有消息边界。直接假设一次 send 对一次 recv 是新手最容易踩的坑，现场表现是偶尔少一段、偶尔两条粘在一起。工程里常见做法是长度前缀：先发 4 字节网络序长度，再发负载；接收端先收满 4 字节，再按长度收满负载，并设置最大长度保护。
bool SendAll(SOCKET s, const char* data, int len) { int sent = 0; while (sent < len) { int n = send(s, data + sent, len - sent, 0); if (n <= 0) return false; // 0 或 SOCKET_ERROR 都按失败处理 sent += n; } return true; } bool SendPacket(SOCKET s, const char* payload, int len) { if (len < 0 || len > 64 * 1024) return false; // 上限按业务定 unsigned int netLen = htonl((unsigned int)len); if (!SendAll(s, (const char*)&netLen, sizeof(netLen))) return false; return SendAll(s, payload, len); } bool RecvAll(SOCKET s, char* data, int len) { int got = 0; while (got < len) { int n = recv(s, data + got, len - got, 0); if (n <= 0) return false; // 0 对端关闭，SOCKET_ERROR 看错误码 got += n; } return true; } bool RecvPacket(SOCKET s, char* out, int maxLen, int* outLen) { unsigned int netLen = 0; if (!RecvAll(s, (char*)&netLen, sizeof(netLen))) return false; int len = (int)ntohl(netLen); if (len < 0 || len > maxLen) return false; // 防止异常长度撑爆缓冲区 if (!RecvAll(s, out, len)) return false; *outLen = len; return true; }send返回值可能小于请求长度，必须循环直到发完或出错；recv返回 0 表示对端正常关闭，返回SOCKET_ERROR要结合WSAGetLastError()判断是超时、断开还是参数错误。长度前缀用htonl/ntohl统一网络序，接收端先校验maxLen再分配或拷贝。业务层不要在收线程里做长时间解析，先把完整包放进队列，否则一个慢解析会拖住整个连接。若协议已经有固定头，也可以把长度放进头里，但边界检查不能省。
4. 阻塞还是select：WinCE下超时、断线与多连接的处理
WinCE 上很多人默认用阻塞 socket，代码短，但一旦对端半开或网络抽风，recv 可能长时间不返回。另一个极端是全改非阻塞，结果 CPU 空转、错误码满天飞。更稳的做法是阻塞 socket 配 select 做超时等待，或者非阻塞配 select 做事件驱动。选择依据不是“哪个高级”，而是你的连接数、线程预算和业务实时性。
4.1 阻塞模式的超时设置与局限
阻塞 socket 可以用SO_RCVTIMEO、SO_SNDTIMEO设置收发超时，但 WinCE 不同 SDK 对选项的支持程度不完全一致，参数类型也可能是毫秒整数。它可以作为第一道保护，不能替代应用层心跳和 select。特别是 connect 超时，很多环境里SO_SNDTIMEO并不按预期生效，所以上一章的 select 连接写法更可控。
bool SetSocketTimeout(SOCKET s, int recvMs, int sendMs) { int tv = recvMs; if (setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (const char*)&tv, sizeof(tv)) != 0) { return false; } tv = sendMs; if (setsockopt(s, SOL_SOCKET, SO_SNDTIMEO, (const char*)&tv, sizeof(tv)) != 0) { return false; } return true; }参数单位按工程 SDK 定义确认，常见是毫秒；设置失败不要直接忽略，至少记录错误码。超时后 recv 返回SOCKET_ERROR，错误码可能是WSAETIMEDOUT或WSAEWOULDBLOCK，要看具体实现。阻塞超时只能让单次调用返回，不能告诉你链路是否还健康，半开连接仍然需要心跳或业务层探测。多连接场景下，一个连接一个阻塞线程会吃掉线程资源，连接数一多就要换模型。
4.2 select模型：把recv从无限等待里拉出来
select 适合“等一会儿看有没有数据”的场景。每次调用前都要重新FD_ZERO、FD_SET，因为 select 会修改集合；返回 0 是超时，大于 0 再判断FD_ISSET，小于 0 看错误码。下面这个封装把可读等待做成固定超时，业务循环里可以定期检查退出标志，不会卡死在 recv。
// 返回 1 可读，0 超时，-1 错误 int WaitReadable(SOCKET s, int timeoutMs) { fd_set rset; FD_ZERO(&rset); FD_SET(s, &rset); timeval tv; tv.tv_sec = timeoutMs / 1000; tv.tv_usec = (timeoutMs % 1000) * 1000; int ret = select(0, &rset, NULL, NULL, &tv); if (ret > 0 && FD_ISSET(s, &rset)) return 1; if (ret == 0) return 0; return -1; } int TryRecv(SOCKET s, char* buf, int len) { int n = recv(s, buf, len, 0); if (n > 0) return n; if (n == 0) return 0; // 对端关闭 int err = WSAGetLastError(); if (err == WSAEWOULDBLOCK) return -2; // 非阻塞下暂无数据 return -1; }timeval的秒和微秒要分别换算，timeoutMs为 0 时表示立即返回，不是无限等待。select 返回可读不代表一定能读到完整包，只代表下一次 recv 不会阻塞，所以仍然要配合RecvAll或状态机。非阻塞 recv 遇到WSAEWOULDBLOCK不是错误，回到 select 继续等；遇到 0 要按对端关闭处理，及时清理连接。多连接时可以把多个 socket 放进同一个 fd_set 轮询，但 WinCE 的 fd_set 容量有限，连接数大时建议分组。
4.3 多线程收发的边界与资源回收
一个连接一个收线程是常见起点，但发送最好走队列加锁，不要多个线程同时往同一个 socket 塞业务包，否则消息边界和顺序都难保证。线程退出时谁关闭 socket 要提前约定：推荐收线程持有并关闭，主线程只置运行标志，不直接 closesocket。下面是一个简化骨架，运行标志在实际工程里用事件或原子操作更稳。
struct ClientCtx { SOCKET s; volatile bool running; }; DWORD WINAPI RecvThread(LPVOID p) { ClientCtx* ctx = (ClientCtx*)p; char buf[1024]; while (ctx->running) { int r = WaitReadable(ctx->s, 1000); if (r == 0) continue; // 超时，回头检查退出标志 if (r < 0) break; // select 错误，退出 int n = recv(ctx->s, buf, sizeof(buf), 0); if (n <= 0) break; // 关闭或错误 // 把 buf[0..n) 投递到业务队列，不要在这里做长耗时解析 } ctx->running = false; closesocket(ctx->s); ctx->s = INVALID_SOCKET; return 0; }volatile bool只能防止编译器把读优化掉，不能保证多核原子性，实际工程建议用InterlockedExchange或事件对象。收线程里不要直接调用可能阻塞很久的业务函数，否则退出标志要等很久才生效。关闭 socket 后把句柄置INVALID_SOCKET，其他线程使用前先判断。发送队列要设上限，网络断开时无限堆积会把嵌入式设备内存吃光，常见做法是超过阈值丢弃旧包或断开重连。
5. 避坑与排查：WinCE TCP通信最常见的五个翻车点
这一章按现场排查看得见的现象来写，每条都按“现象、原因、解决”推进。WinCE 设备一旦装到现场，日志和调试口不一定方便，所以代码里要提前留错误码和计数。下面五条是 WinCE TCP 通信里出现频率很高的翻车点，建议在交付前逐条过一遍。
5.1 连接成功但收发卡死：超时、半开与心跳缺失
现象是客户端显示已连接，服务端也 accept 成功，但十几分钟后双方都不再收发，进程没崩，线程卡在 recv。原因常见有三个：阻塞 recv 没有超时；对端设备掉电或网线拔出后连接进入半开状态；应用层没有心跳，TCP 自身 keepalive 默认时间太长。解决思路是把 recv 从无限等待改成 select 超时等待，同时加应用层心跳和超时计数。
// 收线程里用超时等待，定期检查心跳时间戳 while (running) { int r = WaitReadable(s, 1000); if (r == 0) { if (NowMs() - lastHeartbeatMs > 3 * heartbeatIntervalMs) { break; // 心跳超时，主动断开重连 } continue; } if (r < 0) break; // 正常收数据并更新 lastHeartbeatMs }WaitReadable的超时不要设太长，1 秒左右便于及时响应退出和心跳检查；心跳间隔按业务定，常见 10 到 30 秒，连续 3 次没有心跳再判断断开。不要只依赖SO_KEEPALIVE，它的默认探测周期在嵌入式环境里往往不适合快速发现故障。断开后要关闭旧 socket 再重连，不能在半开连接上反复 send。
5.2 bind失败与重连端口占用：TIME_WAIT和SO_REUSEADDR
现象是服务端重启后 bind 返回失败，错误码WSAEADDRINUSE，等一会儿又好了；或者客户端频繁重连时本地端口被占用。原因是 TCP 连接关闭后进入 TIME_WAIT，旧四元组还没释放。解决是服务端 bind 前设置SO_REUSEADDR，客户端重连不要用固定本地端口，失败后退避重试并记录错误码。
int opt = 1; setsockopt(listenSock, SOL_SOCKET, SO_REUSEADDR, (const char*)&opt, sizeof(opt)); if (bind(listenSock, (sockaddr*)&addr, sizeof(addr)) != 0) { int err = WSAGetLastError(); // WSAEADDRINUSE 时不要立刻死循环重试，退避后再试 }SO_REUSEADDR不是让两个进程同时监听同一端口，具体行为看 SDK 实现；设置后仍要处理 bind 失败。重连策略建议 1 秒、2 秒、4 秒递增，设最大间隔，避免网络刚断时把 CPU 和日志打满。客户端如果调用了 bind 指定本地端口，重连前要关闭旧 socket，否则本地端口可能仍被占用。排查时把WSAGetLastError()打出来，比只看“bind failed”有用。
5.3 结构体直发导致字段错乱：字节序与对齐
现象是两端字段偶尔对不上，重启后有时正常，换编译器或换 SDK 后必现。原因常见是把结构体指针直接 send，结构体里有 padding，字段还有主机序；接收端按同样结构体强转，看似省事，实际边界不可控。解决是手动序列化，固定字段宽度，统一网络序，结构体只作为内存对象，不作为线上格式。
struct Msg { int cmd; short len; char data[6]; }; // 错误示范：padding 和字节序都不可控 // send(s, (char*)&msg, sizeof(msg), 0); char buf[12]; int cmd = htonl(msg.cmd); short len = htons(msg.len); memcpy(buf, &cmd, 4); memcpy(buf + 4, &len, 2); memcpy(buf + 6, msg.data, 6); SendAll(s, buf, 12);#pragma pack(1)只能改对齐，不能改字节序，也不能解决不同编译器对基础类型宽度的差异。线上协议建议用int32_t、uint16_t这类固定宽度类型，或者统一按字节数组读写。长度字段要限制最大值，接收端先校验再拷贝，避免异常包导致越界。调试时把收发十六进制打印出来，比盯着结构体变量猜要快。
5.4 断网检测失效与句柄泄漏：keepalive、closesocket和线程退出
现象是设备运行几天后 socket 数量上涨，最后创建失败；或者断网后程序仍以为连接存在。原因通常是异常路径没有 closesocket，线程退出顺序不对，以及只依赖 TCP keepalive。解决是把 socket 生命周期收口，所有失败分支都走同一个清理函数，应用层心跳判断链路，线程退出前关闭自己持有的句柄。
void CloseSocket(SOCKET& s) { if (s != INVALID_SOCKET) { closesocket(s); s = INVALID_SOCKET; } } // 线程入口统一清理，避免每个 return 前手写 closesocket DWORD WINAPI Worker(LPVOID p) { SOCKET s = (SOCKET)(int)p; // ... 业务 CloseSocket(s); return 0; }把closesocket包一层并置无效，能减少重复关闭和野句柄。不要在主线程关闭 socket 后让工作线程继续 recv，正确顺序是先置退出标志，等工作线程退出，再关闭它持有的句柄；或者约定工作线程自己关。keepalive 可以作为补充，但断线判断主要靠应用层心跳和业务超时。现场可以加一个 socket 计数，创建加一、关闭减一，长期跑一段时间看是否只增不减。
5.5 多线程调用Winsock的初始化与清理顺序
现象是主线程正常，工作线程里 socket 创建失败，或者程序退出时崩溃。原因常见是 WSAStartup 没调用就创建 socket，或者某个线程提前 WSACleanup，导致其他线程还在用的 Winsock 资源被清掉。解决是进程启动时初始化一次，所有网络线程创建之前完成；所有 socket 关闭、线程退出之后再清理。
int main() { if (!InitWinsock()) { return -1; } // 先启动业务线程，再进入主循环 StartTcpServer(9000); // 退出流程：先通知线程停止，等待线程结束，再清理 Winsock g_serverRunning = false; // WaitFor... 或事件通知 WSACleanup(); return 0; }WSAStartup 和 WSACleanup 要配对，但不要在每次重连时配对调用，重连只重建 socket。工作线程里如果必须调用 Winsock 函数，确保初始化已经完成；退出时先停线程再清理。WinCE 上调试多线程资源问题，错误码和句柄计数比单步更有效，尤其是现场无法复现的时候。
6. 进阶：给WinCE TCP链路加上心跳、重连和可验收的日志
把最小闭环和双端流程跑通后，建议再加三样东西：应用层心跳、断线重连退避、可验收的日志计数。心跳包不要复杂，固定头加序号和时间戳即可，双方按同一套序列化规则读写。下面这个结构只做示例，字段宽度固定，发送前转网络序，接收端校验长度和序号回绕。
struct Heartbeat { unsigned int seq; unsigned int timestamp; }; bool SendHeartbeat(SOCKET s, unsigned int seq, unsigned int ts) { char buf[8]; unsigned int netSeq = htonl(seq); unsigned int netTs = htonl(ts); memcpy(buf, &netSeq, 4); memcpy(buf + 4, &netTs, 4); return SendAll(s, buf, 8); }重连不要用固定 100 毫秒死循环，建议按 1 秒、2 秒、4 秒、8 秒退避，设 30 秒上限；每次重连前关闭旧 socket，连接成功后重置退避。日志至少记录连接建立、断开原因、重连次数、收发字节数和心跳超时次数，现场只看“连不上”很难定位。
| 验证场景 | 操作 | 观察点 |
|---|---|---|
| 正常收发 | 两端持续发长度前缀包 | 包序、长度、字节计数是否一致 |
| 断网恢复 | 拔掉网线一段时间再插回 | 心跳超时是否触发、重连退避是否生效 |
| 对端重启 | 服务端重启，客户端保持运行 | 旧连接是否关闭、是否出现句柄只增不减 |
我自己的习惯是：每次在 WinCE 上交付 TCP 模块，先跑最小闭环，再跑断网重连和长时间收发计数，最后才接业务解析。从那以后我每次改收发逻辑，都强制走一遍“半包、粘包、对端关闭、心跳超时”四个用例，不然现场翻车一次，排查成本远高于提前写测试。希望帮到你。
本文还有配套的精品资源，点击获取
