C语言网络编程必知：winsock2.h头文件与ws2_32.lib链接完全指南

简介：本资源为Windows平台网络编程核心头文件 WINSOCK2.H 的标准C语言头文件，面向C/C++初学者、嵌入式开发人员及Windows系统级程序员，用于支持TCP/IP socket编程、网络通信初始化与底层套接字操作。资源包仅含1个.h头文件，体积精简（16KB），可直接集成至VS或MinGW等开发环境，无需额外依赖，适用于网络客户端/服务器开发、协议栈调试及Winsock API学习实践。目前已有1215人下载学习，体现了其在基础网络编程教学与工程实践中的高频使用价值。读者获取后即可立即引用该头文件，调用WSAStartup、socket、bind、connect等关键Winsock函数，结合MSDN文档快速开展UDP/TCP通信实验，掌握Windows下网络编程的初始化流程、错误处理机制及跨版本兼容要点。

1. 为什么C语言网络编程绕不开WINSOCK2这个头文件

很多C语言初学者一路从变量、指针、结构体学过来，自我感觉基本功还算扎实，等到某天想写个TCP通信DEMO或者做一个局域网传输工具时，一上手就看到一个压根没见过的头文件——winsock2.h。不少人的第一反应是百度搜一下，复制一段代码，然后把#include <winsock2.h>放上去编译，结果要么是报一堆LNK2019找不到符号，要么是一堆宏重定义。踩完这些坑才意识到，这个头文件并不是简单包含进来就能用的。

WINSOCK2是Windows平台下C/C++进行网络编程的标准套接字接口，全称是Windows Sockets 2。它本质上是Windows对Berkeley Socket模型的一套实现，但又不完全是照搬，而是扩展了很多Windows特有的能力。你在Linux下写网络程序用sys/socket.h，在Windows下绝大多数情况用的就是winsock2.h。很多教材在讲Socket编程的时候默认拿Linux环境做演示，导致换到Windows环境来实践的时候，很多同学直接被头文件和链接库配置整懵了。这篇内容就是专门来把这个环节梳理清楚的。

这个头文件适合谁看？主要两类人：一类是C语言基础已经学完、想往网络编程方向走的学生，另一类是工作里需要在Windows平台快速写网络工具、但又不想每次都被编译环境折磨的开发者。看完之后，你至少能做到：知道winsock2.h是什么、什么时候该包含它、为什么包含它还不够、报错出现时怎么快速定位。

2. 引入winsock2.h的正确姿势：include顺序与宏定义

2.1 为什么它必须在windows.h之前包含

如果你去翻老的Win32网络程序源码，经常会看到这样一段include组合：

#include <winsock2.h> #include <windows.h>

这个顺序是有讲究的，不是随便排的。因为早期版本的windows.h内部会间接包含winsock.h，也就是Winsock 1.1版本的头文件，而winsock2.h是Winsock 2.0的头文件。如果编译器先处理了windows.h，再处理winsock2.h，两个头文件里面都定义了SOCKADDR_IN这样的结构体、socket()这样的函数声明、一堆网络相关的宏，预处理器就会喷出一大堆重定义错误。

为了绕开这个坑，最稳妥的做法是：把winsock2.h放在所有Windows头文件的前面，让它先被包含，之后windows.h在间接引入winsock.h时，会因为WIN32_LEAN_AND_MEAN或者_WINSOCKAPI_这类宏已经被定义而跳过Winsock 1.1的部分。这也是我在自己的项目里一直坚持的写法。

还有一个偷懒但也非常可靠的方案，是在include之前定义一个宏：

#define WIN32_LEAN_AND_MEAN #include <windows.h> #include <winsock2.h>

WIN32_LEAN_AND_MEAN会告诉windows.h不要包含那些不常用的Windows API头文件，其中就包括了老版的winsock.h，间接规避了冲突。不过，建议不要因为这个宏就放松对include顺序的重视，两者的配合理解会让你在解决别人留下的烂摊子时更有底气。

2.2 只include远远不够：ws2_32.lib链接问题

这是新手最容易卡住的地方之一。很多人写了个最简单的样子：

#include <stdio.h> #include <winsock2.h> int main() { WSADATA wsaData; WSAStartup(MAKEWORD(2, 2), &wsaData); return 0; }

编译能过，链接却报error LNK2019: 无法解析的外部符号 __imp__WSAStartup@8。原因很简单：头文件只负责声明函数长什么样，也就是编译阶段的“约定”；真正让程序能找到函数实现，需要告诉链接器去哪个.lib文件里找。WINSOCK2的实现代码在系统的ws2_32.dll里，而链接器需要的是对应的导入库ws2_32.lib。

解决方式有下面这几种：

我自己写小工具时，一般直接在代码顶部加上：

#pragma comment(lib, "ws2_32.lib")

这样就算把源码发给同事或者拷到另一台电脑上重新编译，也不会因为忘记配置工程而白折腾半小时。

注意：如果你用的是MinGW-w64环境，#pragma comment虽然在部分版本也能识别，但更保险的方式还是编译时加-lws2_32参数。我实测在MSYS2的MinGW-w64 GCC 12.2版本下，#pragma comment(lib, "ws2_32.lib")是可以正常工作的，但在一些老版本或者TDM-GCC上可能会被忽略，所以命令行编译时习惯性带上-lws2_32就万无一失了。

2.3 一个最小可用模板

把上面两小节的内容合起来，一个不会踩坑的最小模板是这样：

#define WIN32_LEAN_AND_MEAN #include <winsock2.h> #include <windows.h> #include <stdio.h> #pragma comment(lib, "ws2_32.lib") int main() { WSADATA wsa; int ret = WSAStartup(MAKEWORD(2, 2), &wsa); if (ret != 0) { printf("WSAStartup failed: %d\n", ret); return 1; } printf("Winsock initialized. version: %d.%d\n", LOBYTE(wsa.wVersion), HIBYTE(wsa.wVersion)); WSACleanup(); return 0; }

这个模板是我在写任何Windows网络程序时的标配开头。先把框架跑起来，再往里填充Socket逻辑。有些新人喜欢一开始就堆一大堆代码，然后报错了都不知道是哪一行引起的，还是建议像这样先小步验证，再逐步扩展。

3. 从WSAStartup到send：WINSOCK2核心API的完整实操流程

3.1 第一步：用WSAStartup完成协议栈初始化

WSAStartup可以说是所有Winsock程序的第一道大门。它的作用是在进程内部加载Winsock协议栈，并协商版本号。这个函数是必须最先调用的，其他任何Socket相关API都要在它之后才能使用，哪怕你只是创建一个最基础的UDP透传Socket。

int WSAStartup( WORD wVersionRequested, // 高位为主版本号，低位为次版本号 LPWSADATA lpWSAData // 返回协议栈详细信息 );

这里的参数用MAKEWORD(2, 2)表示请求Winsock 2.2版本。为什么要协商版本？因为Windows系统本身可能支持不同版本的Winsock，程序请求一个版本，系统返回它能提供的版本，如果两者不兼容，WSAStartup会失败。返回值0代表成功，非零值对应具体的错误码。

有个小细节值得留意：WSAStartup是进程级的初始化，不是每次创建Socket前都要调一次。正常流程是程序启动时初始化一次，程序退出前调用WSACleanup释放资源。如果你在一个消息循环里反复调WSAStartup和WSACleanup，性能损耗非常明显，还可能导致一些内部状态错乱。

另外，WSAStartup并不只是“走个过场”，它背后会做Winsock协议的动态加载和引用计数管理。也就是说，多次调用会让引用计数递增，每调一次WSAStartup就得对应一次WSACleanup，不然资源释放不干净。写DLL的时候这个坑尤其容易踩，因为DLL的入口和出口都会涉及到初始化和清理的逻辑。

3.2 创建Socket到建立连接：bind、listen、accept、connect

如果说WSAStartup是打开一扇门，那后面的socket、bind、listen、accept、connect这一串函数才是真正的跑道。

创建Socket：

SOCKET s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (s == INVALID_SOCKET) { int err = WSAGetLastError(); // 处理错误 }

三个参数分别代表地址族（IPv4还是IPv6）、套接字类型（流式还是数据报）、协议。TCP用SOCK_STREAM，UDP用SOCK_DGRAM。不需要死记硬背，理解就好：AF_INET是IPv4，对应struct sockaddr_in；AF_INET6是IPv6，对应struct sockaddr_in6。这里提一句，很多老代码会写PF_INET，那是老BSD风格的遗留，实测在Windows上AF_INET和PF_INET值一样，但语义上AF_更贴近“地址族”，建议直接用AF_INET。

绑定地址：

服务端要接受连接，必须先绑定一个IP和端口：

struct sockaddr_in addr; addr.sin_family = AF_INET; addr.sin_port = htons(8888); addr.sin_addr.s_addr = htonl(INADDR_ANY); // 监听所有网卡 bind(listen_sock, (struct sockaddr*)&addr, sizeof(addr));

这段代码里有两处很容易让C语言新手紧张：htons和htonl是干嘛的，以及为什么bind要强制转换成struct sockaddr*。后者是因为bind这个函数是通用接口，设计出来就是为了兼容IPv4和IPv6，所以第二参数用了一个更“原始”的结构体指针来统一传参。这就类似于C语言里的void*，你在调用时手动转成具体类型。前者htons的作用，我在后面专门讲字节序的时候会细说，这里先记住：端口和IP地址都要转成网络字节序。

监听与接受连接：

listen(listen_sock, SOMAXCONN); SOCKET client_sock = accept(listen_sock, NULL, NULL);

listen的第二个参数表示等待队列的最大长度，SOMAXCONN是系统默认的最大值。accept会阻塞当前线程，直到有客户端连接进来。很多人第一次写服务端程序时，在这里会疑惑：既然accept会阻塞，那我要同时处理多个客户端怎么办？这就涉及到多线程、select或者IOCP等模型了，属于下一步要进阶的内容。初学者前期可以先用单线程阻塞模式把整个流程跑通，再慢慢升级。

客户端发起连接：

struct sockaddr_in server_addr; server_addr.sin_family = AF_INET; server_addr.sin_port = htons(8888); inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr); connect(client_sock, (struct sockaddr*)&server_addr, sizeof(server_addr));

客户端不需要bind，因为操作系统会为它自动分配一个临时端口。注意这里的inet_pton在主流的Win7及以上系统都支持，如果你的目标环境是上古Windows XP，那可能得用inet_addr替代。我在实际开发中统一用inet_pton，因为支持IPv6文本格式转换，方便以后扩展。

3.3 网络字节序：为什么端口和IP要转来转去

字节序是C语言网络编程里绕不开的经典话题，同时也是很多自学者容易忽略的细节。简单来说，不同的CPU架构在内存里存放多字节整数的方式不同，分为大端和小端。x86架构是典型的小端，而网络协议规定数据在网络上传输时统一使用大端字节序。这就导致本地整数和网络传输字节序大概率不一致，所以需要转换函数来对接。

实际操作中，你不需要手动去判断CPU是大端还是小端，直接用API就行：

• htons：将16位整数从主机字节序转换为网络字节序，通常用来转端口号。
• htonl：将32位整数从主机字节序转换为网络字节序，通常用来转IP地址。
• ntohs和ntohl：作用相反，从网络字节序转回主机字节序，通常在accept之后解析对方端口和IP时使用。

还是以端口8888为例。8888的十六进制是0x22B8，在小端机器上存为B8 22，而网络传输要求22 B8，htons(8888)就是做这个转换的。如果你忘了转换，直接把8888赋给sin_port，那么实际监听的端口可能是0xB822换算出来的值，也就是47138，客户端连8888端口自然会失败。这类问题的排查过程很痛苦，因为代码看起来哪里都没错。

顺带提一下，字符串形式的IP地址转成32位整数的函数不止inet_addr和inet_pton两个，还有个inet_aton在Linux下更常用。Windows下inet_pton已经够用了，用法也比较现代、安全。

3.4 收尾与错误处理：WSACleanup和WSAGetLastError

有朋友在实习时写过一段网络程序，功能是完成了，但每次关闭程序时任务管理器里都能看到残留的进程句柄，后来发现是没调closesocket和WSACleanup。这种资源泄漏在开发调试阶段问题不大，但如果你的程序是长期运行的服务器进程，日积月累会让句柄耗尽，最终导致系统拒绝创建新的Socket。

一个健壮的收尾流程是这样的：

closesocket(client_sock); closesocket(listen_sock); WSACleanup();

closesocket关闭Socket句柄，WSACleanup释放Winsock初始化的资源。顺序不能反，先关Socket，再清理Winsock环境。多说一句，closesocket和C标准库的close、fclose不是一回事，Windows专门为Socket提供了这个API，不要混用。

错误处理方面，WSAGetLastError()等价于Windows API里的GetLastError()，专门拿Socket调用失败的错误码。错误码非常多，但常见的有这些：

调试时，我习惯写一个错误输出函数，把错误码和对应的文本一起打印出来，这样比盯着一个数字猜半天效率高很多。别嫌麻烦，写工具程序时多这十几行代码，排查问题的时间能省下一大截。

3.5 一个完整的TCP回射Server代码示例

把前面几个小节串起来，写一个最简单的TCP回射服务端：

#define WIN32_LEAN_AND_MEAN #include <winsock2.h> #include <windows.h> #include <stdio.h> #pragma comment(lib, "ws2_32.lib") int main() { WSADATA wsa; WSAStartup(MAKEWORD(2, 2), &wsa); SOCKET listen_sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (listen_sock == INVALID_SOCKET) { printf("socket failed: %d\n", WSAGetLastError()); WSACleanup(); return 1; } struct sockaddr_in addr; addr.sin_family = AF_INET; addr.sin_port = htons(8888); addr.sin_addr.s_addr = htonl(INADDR_ANY); if (bind(listen_sock, (struct sockaddr*)&addr, sizeof(addr)) == SOCKET_ERROR) { printf("bind failed: %d\n", WSAGetLastError()); closesocket(listen_sock); WSACleanup(); return 1; } if (listen(listen_sock, SOMAXCONN) == SOCKET_ERROR) { printf("listen failed: %d\n", WSAGetLastError()); closesocket(listen_sock); WSACleanup(); return 1; } printf("server listening on 8888...\n"); SOCKET client = accept(listen_sock, NULL, NULL); if (client == INVALID_SOCKET) { printf("accept failed: %d\n", WSAGetLastError()); closesocket(listen_sock); WSACleanup(); return 1; } char buf[1024]; int recv_len = recv(client, buf, sizeof(buf) - 1, 0); if (recv_len > 0) { buf[recv_len] = '\0'; printf("recv: %s\n", buf); send(client, buf, recv_len, 0); } closesocket(client); closesocket(listen_sock); WSACleanup(); return 0; }

这段代码算是一个新手友好的最小可运行示例，包含了初始化、建Socket、绑定、监听、接受连接、收发数据、资源释放的全部环节。把这段跑通之后，再往多线程、非阻塞、select模型的方向扩展就会顺很多。

4. 常见报错与排查实录：链接失败、红色波浪线、预编译头文件

4.1 VSCode里winsock2.h找不到或红色波浪线

VSCode这几年成了C语言学习的主流编辑器，配置简单、扩展丰富。但是很多人在VSCode里写入了#include <winsock2.h>之后，发现编辑器画了一根红色波浪线，提示找不到该头文件。这个问题的本质不是代码错了，而是IntelliSense不知道去哪找Windows SDK的头文件。

解决步骤其实不复杂，我按实际操作顺序整理一下：

1. 安装C/C++扩展（ms-vscode.cpptools），这是微软官方扩展，支持语法高亮、补全和调试。

2. 按Ctrl+Shift+P打开命令面板，输入C/C++: Edit Configurations (UI)。

3. 在“Include path”这一项中，添加Windows SDK的Include目录。具体路径因系统而异，常见的是：

   • C:\Program Files (x86)\Windows Kits\10\Include\<版本号>\ucrt
   • C:\Program Files (x86)\Windows Kits\10\Include\<版本号>\um
   • C:\Program Files (x86)\Windows Kits\10\Include\<版本号>\shared

   其中winsock2.h就位于um目录下。你可以在资源管理器里实际看一眼，确认一下目录名称是不是对的。

4. 配置完成后，重启VSCode或者重新加载窗口，红色波浪线应该就能消失。

还有一种情况是，编译本身没问题，但Ctrl+点击跳转不到头文件定义。这个通常是IntelliSense的includePath没有生效，或者.vscode/c_cpp_properties.json文件路径配置出了问题。直接打开这个JSON文件检查一下includePath数组，确保有Windows Kits相关路径即可。顺带提一句，如果你在项目里用了“万能头文件”#include <bits/stdc++.h>，那是GCC环境的专利，在MSVC环境下是不存在的，别把这个混到Windows项目里来。

4.2 链接错误LNK2019/LNK1120的根源与处理

在我帮人排查过的网络程序编译问题里，这类错误是出现频率最高的。典型报错是：

error LNK2019: 无法解析的外部符号 __imp__WSAStartup@8，函数 _main 中引用了该符号 error LNK1120: 1 个无法解析的外部命令

这个信息已经非常明确了：代码里调用了WSAStartup，但链接器找不到它的实现。解决办法就是前面反复强调的：链接ws2_32.lib。

用Visual Studio的图形界面配置路径是：

• 右键项目 -> 属性 -> 链接器 -> 输入 -> 附加依赖项
• 在列表中添加ws2_32.lib

我自己更推荐的是在源码开头加#pragma comment(lib, "ws2_32.lib")。原因很简单：配置文件跟源码是分开的两个东西，源码发到别人手上，配置就丢了；而#pragma直接写在源码里，属于自描述文件，谁拿到都能直接编译。

如果你用的是GCC命令行，那对应的是：

gcc -o server.exe server.c -lws2_32

忘记加-lws2_32就会出现同样的问题。这个坑普遍到什么程度？很多初学者在VSCode里配好了.vscode/tasks.json，里面负责编译的参数往往只有gcc -g -o xxx xxx.c，根本没带-lws2_32，所以头文件能解析，编译能通过，链接必报错。

还有一类LNK2019不是Winsock的问题。如果你在Release x64版本下看到类似“无法打开预编译头文件: x64\Release\xxx.pch”的报错，大概率是预编译头（PCH）设置出了问题。这通常发生在你把一个原来用VS创建的项目拷贝到另一台机器上，路径变了，但.vcxproj里缓存的中间目录还指向旧路径。解决办法是：在Visual Studio里选择“项目”->“重新扫描解决方案”，或者直接清理解决方案再重新生成，让编译器重新生成PCH文件。如果还不行，可以在项目属性里把“预编译头”选项改成“不使用预编译头”，代价是编译速度会略微下降，但能保证项目正常编译。

4.3 winsock2.h和windows.h的宏冲突

这个主题我前面已经提过两次了，但实际遇到问题时，报错形态可能会让人摸不着头脑。最常见的报错是：

error C2011: 'sockaddr' : 'struct' type redefinition error C2011: 'timeval' : 'struct' type redefinition

看到这种“结构体重定义”的错误，第一反应不应该是怀疑自己的代码，而是检查include顺序。绝大多数情况下，是因为windows.h被包含在了winsock2.h的前面。

还有一种隐蔽的冲突场景：有些第三方库，比如某些图像库、串口库，它们的头文件内部会自己去包含windows.h，你没办法控制它们的位置。这时候可以在#include <winsock2.h>前先定义：

#define _WINSOCKAPI_ #include <winsock2.h>

这个宏的作用是阻止windows.h内部再去包含winsock.h。我实测有效，但要注意这个宏必须在任何windows.h包含之前定义才生效。还有一种做法是直接用#include <winsock2.h>替换掉原来的#include <windows.h>，前提是你确认项目里没有用到windows.h独有的一些API。

另外，timeval结构体重定义在MinGW环境下也比较常见。如果你不想动include顺序，可以考虑在包含头文件之前定义_TIMEVAL_DEFINED来跳过timeval的重复定义，但这属于绕过，本质上还是会掩盖问题，建议还是把头文件顺序理清楚。

4.4 一个容易忽略的陷阱：socket编程里的字符串和缓冲区

说到C语言，字符串处理是基本功。很多人在写网络程序时会在缓冲区处理上翻车，最典型的就是用strlen去算发送长度：

char buf[] = "hello, server"; send(client, buf, strlen(buf), 0);

这里有个隐藏问题：strlen返回的是字符串长度，不包含末尾的\0。如果是文本协议，这倒没什么问题；但如果你传输的数据里可能包含\0字节，比如结构体或者二进制文件，必须改用sizeof或者显式指定长度。另一处常见隐患是recv的返回值。recv返回的是实际接收到的字节数，这个值可能小于缓冲区大小，也可能为0代表对端关闭连接，也可能是SOCKET_ERROR，三种情况必须分开处理，不能想当然认为一次recv就能收完整个数据包。

在C语言的内存管理语境下，缓冲区越界是隐蔽炸弹。比如：

char buf[64]; recv(client, buf, 1024, 0); // buf只有64字节，但recv试图写1024字节

这种错误在调试的时候未必立刻崩溃，但可能在某次运行中被系统检测到栈破坏，然后弹出一个莫名奇妙的断言窗口。我自己在写网络程序时，尽量用固定大小缓冲区，然后在recv之前把剩余空间算清楚，收完后手动补\0，把缓冲区当作有边界的内存区域来管理。

5. 环境配置冷知识：从VSCode到命令行

5.1 Visual Studio vs MinGW-w64

同样是C语言写Windows网络程序，不同的工具链对winsock2.h的支持程度大同小异，但一些小差异还是值得注意。

Visual Studio使用MSVC编译器，Windows SDK是自带的，只要安装了“使用C++的桌面开发”工作负载，winsock2.h、ws2_32.lib就都在了，不需要额外配置。

MinGW-w64则不同，它用的是GCC编译器，需要你指定头文件和库文件的搜索路径。如果你是从MSYS2或者WinLibs安装的MinGW，一般已经自带了Windows SDK相关的头文件和导入库，用下面的命令就可以编译：

gcc -o server.exe server.c -lws2_32

如果提示找不到winsock2.h，先检查MinGW安装目录下的include文件夹里有没有这个文件，没有的话就要检查一下是不是装的是裸GCC而没有带Windows API头文件。有些精简版的GCC套件确实不含Win32 API头文件，建议直接换成完整版WinLibs。

5.2 在VSCode里配置tasks.json实现一键编译

VSCode环境下写C语言项目，运行编译任务是最常用的调试方式之一。我参考网上常见的配置，整理了一个针对Winsock项目的tasks.json：

{ "version": "2.0.0", "tasks": [ { "label": "build winsock", "type": "cppbuild", "command": "gcc", "args": [ "-g", "main.c", "-o", "main.exe", "-lws2_32" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [ "$gcc" ] } ] }

注意args里的-lws2_32，少了这个参数，你的程序链接时百分百报错。如果你的环境是MSVC，用cl.exe编译的话，对应的命令是：

cl main.c /Fe:main.exe /link ws2_32.lib

MSVC里头文件路径不需要手动指定，装了Windows SDK就默认能找到；但链接参数ws2_32.lib不能省。

5.3 为新手准备的万能模板库

我习惯把自己常用的Win32网络程序模板存到一个固定目录里，每次新建项目直接拷贝一份改改。模板里面做了三件事：版本宏定义、包含正确的头文件顺序、链接库声明。这样哪怕某天我必须用一台全新的电脑、空白的环境，拉下来代码也能快速编译。

在这段模板里，我还会顺手定义一个打印错误码的工具函数：

static void print_win_error(const char* tag) { int err = WSAGetLastError(); printf("[%s] error code: %d\n", tag, err); }

调试时在关键Socket调用后面加上这个，加上system("pause")，就能在控制台窗口一闪而过之前把错误信息留住。很多网上教程里没有提到这个小技巧，但实际上对新手来说，控制台窗口一闪而过真的是最让人崩溃的事情之一。

6. 写在最后的实操心得

WINSOCK2这个东西，单独拿出来看并不难，难的是它和C语言本身的特性以及Windows平台的编译体系纠缠在一起，导致很多人在搞懂之前就已经被各种报错劝退了。我自己刚学的时候也经历过那种绝望感：明明代码就是照着书敲的，为什么编译出来全是错。

后来总结了三条属于自己的经验。第一，永远先确认环境再怀疑代码。遇到编译报错，先看路径、看include顺序、看有没有链接ws2_32.lib，这三样没问题再研究业务逻辑。第二，不要一次写太多代码。每次只验证一小块功能，比如先跑通WSAStartup，再跑通socket创建，再往下走。万金油式的一大坨代码是最难排查的。第三，错误码一定要打印出来。很多问题你盯着代码看半天看不出来，但把WSAGetLastError()的返回值一对照文档，原因就摆在眼前了。

最后再分享一个小技巧：如果你在调试服务器程序时发现端口一直显示被占用，多半是上一次运行的程序没有正常关闭Socket。Windows下可以用netstat -ano | findstr 8888查到占用进程的PID，再用taskkill /PID <pid> /F杀进程。这个操作我几个月前帮学弟排查问题时用过一次，他当时已经卡了整整一下午，结果两分钟搞定，整个人都愣住了。

网络编程这条路，从winsock2.h这个头文件开始，后面还有一整个精彩的世界在等着你。先把地基打好，后面的路会越走越顺。

本文还有配套的精品资源，点击获取