recv() 不保证一次收完所有数据，必须循环调用直至读够预期长度或连接关闭；解析文件需先循环读满长度字段再按其值读内容；write() 同样需循环写入并检查返回值；跨平台需适配 Winsock 初始化与错误码获取。
recv() 读取文件数据时为什么总丢字节？
因为 recv() 不保证一次收完所有数据，它只按当前 TCP 缓冲区可用量返回字节数，可能远小于你期望的文件块大小。尤其在高延迟、弱网或大文件场景下，recv() 返回值经常是几十到几百字节，甚至 0（对端关闭）或 -1（错误）。
- 必须用循环调用
recv()，直到累计读够预期长度（比如文件头声明的大小）或遇到连接关闭 - 别直接把
recv()返回值当“本次收到的完整包”，它只是“这次内核愿意给你的那部分” - 检查返回值：-1 要看
errno（如EAGAIN、EWOULDBLOCK在非阻塞模式下合法；ETIMEDOUT或ECONNRESET就得终止） - 示例关键逻辑：
int total = 0; while (total < expected_size) { int n = recv(sockfd, buf + total, expected_size - total, 0); if (n > 0) total += n; else if (n == 0) break; // 对端关闭 else if (n == -1 && errno != EAGAIN && errno != EWOULDBLOCK) break; }
如何安全解析文件长度并防止粘包？
TCP 是字节流，没有消息边界。如果服务端发的是“4 字节长度 + 实际文件内容”，客户端必须先准确读出这 4 字节，再按其值读后续数据——否则极易把长度字段和文件内容混在一起，导致后续全错。
- 长度字段建议用网络字节序（
htonl()发，ntohl()收），避免大小端不一致 - 不要假设前 4 字节一定能一次性
recv()到，同样要循环读满 4 字节 - 如果协议允许，加简单校验（如长度上限检查：若
ntohl(len) > 100 * 1024 * 1024，直接断连，防内存耗尽） - 别用字符串
"END"或\0做分隔符——二进制文件里这些字节完全合法，会误截断
write() 写文件时卡住或写入不全怎么办？
write() 和 recv() 一样，不保证一次写完全部缓冲区。尤其在磁盘慢、IO 负载高或使用带缓冲的 FILE*（如 fwrite()）时，容易只写入一部分就返回。
- 对裸文件描述符，必须循环调用
write()，直到写完全部buf长度 - 避免混用
write()和fwrite()操作同一文件（缓冲冲突，行为未定义） - 打开文件时加
O_SYNC或定期fsync()？通常不必——除非要求强持久化；但要注意fsync()是阻塞操作，大文件会明显拖慢吞吐 - 更稳妥做法：用
open()带O_WRONLY | O_CREAT | O_TRUNC，然后每次write()后检查返回值是否等于本次尝试写入长度
Windows 下 recv() 和 send() 的兼容性坑
Windows 的 Winsock 要求显式初始化，且 recv()/send() 错误码不是 errno，而是通过 WSAGetLastError() 获取；SOCKET 类型也不是 int。
立即学习“C++免费学习笔记（深入）”；
- 必须在程序开头调用
WSAStartup(MAKEWORD(2,2), &wsaData)，结束前调用WSACleanup() - 错误判断不能写
if (ret == -1 && errno == EAGAIN)，而要写if (ret == SOCKET_ERROR && WSAGetLastError() == WSAEWOULDBLOCK) - 关闭 socket 用
closesocket()，不是close() - 跨平台代码中，建议封装一层
my_recv()，内部按平台分支处理错误码和类型转换
实际跑通的关键不在“怎么写第一行”，而在每处 IO 调用后都老老实实检查返回值、区分临时错误和永久错误、并补足缺失字节——这些地方一跳过，文件就大概率损坏或中断。
