Windows下socket编程必须先调WSAStartup()初始化Winsock，否则socket()返回INVALID_SOCKET；connect()在非阻塞模式下返回-1且错误码为WSAEWOULDBLOCK属正常；send()/recv()需循环调用以确保数据完整收发。
Windows 下用 socket() 前必须调用 WSAStartup()
直接调 socket() 会返回 INVALID_SOCKET，错误码是 WSANOTINITIALISED。这不是函数写错了，是 Windows 的 Winsock DLL 没初始化。
必须在任何 socket 函数前调一次 WSAStartup()，且程序退出前配对调 WSACleanup()：
WSADATA wsaData;
int result = WSAStartup(MAKEWORD(2, 2), &wsaData);
if (result != 0) {
printf("WSAStartup failed: %d\n", result);
return 1;
}
// ... 后续 socket 操作
WSACleanup();常见坑：MAKEWORD(2, 2) 表示请求 Winsock 2.2 版本；若传 MAKEWORD(1, 1)，在较新系统上可能失败；不调 WSACleanup() 不影响单次运行，但长期运行或频繁启停会泄漏资源。
创建 TCP 客户端连接时，connect() 返回 -1 不一定代表失败
在非阻塞模式下，connect() 立即返回 -1 并设 errno（Linux）或 WSAGetLastError()（Windows）为 EINPROGRESS（Linux）或 WSAEWOULDBLOCK（Windows），这是正常中间态，表示连接正在后台进行。
立即学习“C++免费学习笔记（深入）”；
判断是否真正连上，需用 select() 或 poll() 等待 socket 可写（write-ready），再调 getsockopt(... SO_ERROR ...) 检查错误值是否为 0：
- Linux：检查
errno是否为EINPROGRESS→ 用select()等待可写 →getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len)，err == 0才算成功 - Windows：同理，但错误码用
WSAGetLastError()判断是否为WSAEWOULDBLOCK，后续流程一致 - 阻塞模式下可跳过这步，但会卡住线程 —— 实际项目中几乎没人这么干
send() 和 recv() 不保证一次传完所有数据
哪怕只发 1KB，send() 也可能只成功写入 300 字节并返回 300；同样，recv() 可能只收到前 200 字节就返回。这是 TCP 流式协议的天然行为，不是 bug。
要发完整数据，得循环调用 send() 直到所有字节发出；收完整包则需循环 recv() 直到读够预期长度（或遇到协议定义的结束标记）：
int send_all(int sock, const char* buf, int len) {
int sent = 0, n;
while (sent < len) {
n = send(sock, buf + sent, len - sent, 0);
if (n <= 0) return -1; // 错误或断连
sent += n;
}
return sent;
}注意：send() 在连接关闭时可能返回 0（罕见）或 -1；recv() 返回 0 表示对端已关闭连接（FIN 包到达），这是合法终止信号，不是错误。
服务端 accept() 返回的新 socket 是独立的通信端点
很多人误以为 accept() 返回的是原监听 socket 的“别名”，其实它是一个全新 socket，有自己的缓冲区、状态和文件描述符（fd）。原监听 socket 继续保持监听，新 socket 专用于与该客户端通信。
这意味着：
- 不能对新 socket 调
listen()—— 会失败 - 关闭新 socket 不影响监听 socket，反之亦然
- 多客户端并发时，每个客户端对应一个独立 socket，需单独管理其读写和生命周期
- 如果用
fork()或线程处理每个连接，父子/线程间要明确谁负责close()新 socket，避免 fd 泄漏
一个容易被忽略的细节：新 socket 默认继承监听 socket 的一些属性（如非阻塞标志），但超时、SO_REUSEADDR 等选项不继承，需要显式设置。
