recv()会一次收到多个包或半个包，因为TCP是字节流协议，不保留send()边界，需靠固定长度包头（如4字节网络序payload长度）配合缓冲区累积解析。
为什么 recv() 会一次收到多个包或半个包
Socket 是字节流，不是消息队列。TCP 不保证 send() 的边界，recv() 也不按发送次数返回——它只管从内核缓冲区尽可能多地拷贝当前可用字节。所以你发了两次 send(sock, "HEAD\0\0\0\x10", 8) 和 send(sock, "data...", 256)，对端可能一次 recv() 拿到全部 264 字节，也可能第一次只拿到前 12 字节（包头 + 部分长度字段），第二次才拿到剩下内容。
粘包/半包本质是应用层协议缺失：你没定义“一个完整包”长什么样，系统自然不会替你切分。
解决思路只有一个：在数据前加固定长度的包头，把「本包总长」或「载荷长度」显式编码进去，再靠这个长度做缓冲和截断。
如何设计一个靠谱的二进制包头结构
别用字符串、别用变长字段、别依赖字节序以外的任何东西。最简方案就是 4 字节整数存 payload 长度（含或不含包头自己，要统一）。
立即学习“C++免费学习笔记（深入）”；
-
struct PacketHeader { uint32_t payload_len; };—— 推荐，清晰且跨平台 - 必须用网络字节序（大端），收发前调
htonl()/ntohl()，否则 x86 和 ARM 对端直接解析错 - 包头长度必须固定（比如 4 字节），否则你无法确定什么时候能开始读 payload
- 不要把校验和、类型字段塞进包头又不固定长度——除非你真需要，否则纯属增加解析复杂度和出错概率
示例：发一个 1024 字节的文件块，先填 htonl(1024) 到 4 字节缓冲区，send() 这 4 字节；再 send() 后续 1024 字节数据。
recv() 怎么确保凑够包头再读 payload
不能假设一次 recv() 就能拿到完整包头。真实网络中，哪怕只有 4 字节，也可能被拆成两次返回（尤其高延迟或低负载时）。
- 维护一个接收缓冲区（如
std::vector<uint8_t></uint8_t>），每次recv()都追加进去 - 先检查缓冲区是否 ≥ 4 字节：不够就继续等；够了就用
ntohl()解出payload_len - 再检查缓冲区总长是否 ≥
4 + payload_len：不够就继续等；够了就把前 4 字节丢掉，取接下来payload_len字节作为完整包，剩余字节留在缓冲区供下次处理 - 务必检查
recv()返回值：0 表示对端关闭，-1 且errno == EAGAIN/EWOULDBLOCK表示暂时无数据（非阻塞模式下）
关键点：所有判断都基于缓冲区当前状态，而不是 recv() 单次返回值。漏掉这个逻辑，就会在边界情况（如包头跨两次 recv）下直接解析崩溃。
文件传输时 payload 里还能不能嵌套包头
可以，但没必要。文件传输场景下，你通常只需要一个外层包头声明「本次发送的是文件第 X 块，共 Y 字节」，然后把原始文件块二进制原样塞进去即可。
- 如果在 payload 里再放一套包头（比如每个 chunk 再带小 header），等于重复造轮子，还容易让两端解析逻辑错位
- 真正要注意的是：文件块大小建议设为 4KB–64KB（避开 TCP MSS 极端值），太小导致包头开销占比高，太大则内存占用高、首包延迟明显
- 别忘了处理最后一块：它的
payload_len必然小于常规块大小，接收端不能硬编码期望固定大小
最易忽略的一点：包头里的长度字段是 payload 长度，不是整个包长度。如果你把包头长度也算进 payload_len，接收端解出来就会多读 4 字节，后续所有包全错位——这种 bug 往往要抓包才能定位。
