recv一次接收字节数不确定，取决于TCP缓冲区可用数据量，可能为1字节、512字节、0（对端关闭）或-1（错误），需循环调用直至收完指定长度或对端关闭。
recv 一次能收多少字节？别直接用固定 1024
recv 不保证一次性收完文件所有数据，它只按当前 TCP 缓冲区可用字节数返回，可能返回 1 字节、512 字节，甚至 0（对端关闭）或 -1（出错）。硬写 recv(sock, buf, 1024, 0) 然后直接写入文件，会导致文件内容错乱或截断。
正确做法是循环调用 recv，直到确认“该收的都收完了”。常见策略有两种：
- 服务端先发 4 字节文件长度（
uint32_t，注意网络字节序），客户端先recv这 4 字节，再循环收满对应字节数 - 服务端发送完毕后主动
shutdown(sock, SHUT_WR)，客户端recv返回 0 时视为结束（适合小文件或可信内网）
推荐第一种——可控、健壮、不依赖连接关闭语义。
ofstream 写入前必须检查是否打开成功
ofstream 构造或 open() 失败时不会抛异常（默认行为），is_open() 返回 false，但后续 << 或 write() 会静默失败。你看到文件为空或部分写入，大概率是这里没校验。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 用
std::ofstream file(path, std::ios::binary);显式指定binary模式，避免 Windows 下换行符被误转 - 立即检查：
if (!file.is_open()) { perror("ofstream open failed"); return -1; } - 写入后可调用
file.flush()并检查file.good()，尤其在大文件场景下
recv + write 组合时缓冲区大小和错误处理不能省
每次 recv 返回值 n 是实际接收字节数，必须用这个 n 去调用 file.write(buf, n)，而不是固定写 sizeof(buf)。否则会把栈上未初始化内存也写进文件。
关键细节：
-
recv返回 -1 时，需检查errno：若为EINTR可重试；EAGAIN/EWOULDBLOCK在非阻塞模式下正常，需轮询或换 select/poll；其他错误（如ENOTCONN）应中止 - 定义缓冲区用
std::vector<char> buf(8192);比裸指针安全，buf.data()可直接传给recv - 不要用
std::endl写二进制文件——它会刷新且加 '\n'，改用\n或直接write()
示例片段：
std::vector<char> buf(8192);
ssize_t n;
while (total_received < expected_size) {
n = recv(sock, buf.data(), buf.size(), 0);
if (n > 0) {
file.write(buf.data(), n);
total_received += n;
} else if (n == 0) {
break; // 对端关闭
} else {
if (errno == EINTR) continue;
perror("recv failed");
break;
}
}
大文件传输要防阻塞和超时，别让 recv 卡死
默认 socket 是阻塞的，如果网络中断或对方卡住，recv 会一直挂起，整个程序假死。生产环境必须设超时。
两种轻量方案：
- 用
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv))，其中tv是struct timeval，设 30 秒较稳妥 - 改用
select()或poll()先判断 socket 是否可读，再调recv，便于集成到事件循环中
注意：SO_RCVTIMEO 超时后 recv 返回 -1 且 errno == EAGAIN，不是错误，要继续循环，而非退出。
另外，频繁小包写磁盘性能差，可在内存累积几 MB 再刷一次 file.write()，但得权衡内存占用与断电丢数据风险。
