recv()会读到多个或半个消息，因TCP是无消息边界的字节流，需应用层通过定长包、分隔符或长度前缀等协议机制自行处理粘包与半包问题。
为什么 recv() 会一次性读到多个消息或只读到半个消息
TCP 是字节流协议，没有“消息边界”这个概念。send() 调用多少次、每次发多长，和 recv() 实际收到的字节数没有一一对应关系。操作系统内核把数据当成连续字节塞进缓冲区，应用层怎么读、读多少，全看你自己怎么调用 recv() —— 它只负责从内核缓冲区“尽量拿”，不保证拿的是完整业务消息。
常见错误现象：recv() 返回 1200 字节，但你的协议规定每条消息固定 512 字节，结果一次读进了两条半；或者你期待一条 512 字节的消息，却只收到前 200 字节，后续 312 字节在下一次 recv() 才来。
- 使用场景：自定义二进制协议（如游戏登录包、IoT 设备心跳）、基于 TCP 的 RPC 或私有通信中间件
- 不要依赖
send()和recv()的调用次数匹配 —— 这是初学者最常踩的坑 -
recv()的flags参数（比如MSG_WAITALL）在非阻塞模式下无效，在阻塞模式下也只对单次调用生效，无法解决跨包问题 - 即使开了
TCP_NODELAY（禁 Nagle），也不能消除粘包/半包，它只影响小包合并时机，不提供消息分界
如何判断一条完整消息已经收齐
核心思路就一个：自己定义边界。TCP 不给，你就得靠协议层补上。常见做法有三类，选哪种取决于你的协议设计约束。
- 定长包：每条消息严格
sizeof(struct msg)字节。简单但浪费带宽，且无法承载变长字段 - 分隔符：用特殊字节（如
\n、\x00）结尾。适合文本协议，但业务数据里若含该字节就得转义，否则解析错位 - 长度前缀：最通用。先读固定长度的 header（如 4 字节 uint32_t 表示 body 长度），再按该长度读 body。注意字节序（网络字节序 vs 主机字节序）
示例（长度前缀）：struct { uint32_t len; char data[]; }。必须分两步读：先确保收齐 4 字节 header，解析出 len，再循环 recv() 直到收齐 len 字节的 body —— 中间任何一次 recv() 返回值小于预期，都得继续等。
缓冲区管理不当导致的典型崩溃
很多实现直接把 recv() 的数据追加到一个全局 buffer 里，但忘了“已处理”和“未处理”的边界。结果就是：上一轮没读完的半包，和下一轮新来的数据混在一起，解析逻辑永远对不上。
- 必须维护一个可增长的接收缓冲区（如 C 的
malloc+realloc，Go 的bytes.Buffer，Python 的bytearray），并记录当前已消费偏移（consumed） - 每次
recv()后，把新数据追加到缓冲区末尾，然后从consumed开始扫描，尝试提取完整消息。成功则更新consumed += 消息总长；失败则保留未消费部分，等待下次数据 - 不清理已消费数据？内存缓慢泄漏；清早了？半包被删掉，再也拼不回来
- 尤其注意：TCP 可能一次
recv()带来多个完整消息（粘包），解析逻辑必须支持循环提取，不能只取第一个
Go / Python / Rust 中容易忽略的底层细节
高级语言封装了 socket，但没封装粘包逻辑。它们的 conn.Read()（Go）、socket.recv()（Python）、std::net::TcpStream::read()（Rust）行为和 C 的 recv() 一致 —— 仍是字节流读取，返回实际读到的字节数，不保证消息完整性。
- Go 的
bufio.Reader提供ReadBytes()和ReadString()，看似解决分隔符问题，但遇到半包时会阻塞等待，且无法处理二进制分隔符（比如\x00在字符串中截断） - Python 的
socket.makefile()同样依赖换行符，且内部缓冲机制可能掩盖半包问题，调试困难 - Rust 的
tokio::net::TcpStream配合BufReader也是类似逻辑，别以为用了 async 就自动分包 - 所有语言里，如果你用
recv(1024)或等效接口，而消息大于 1024 字节，必然出现半包 —— 缓冲区大小不是协议边界
真正要命的点在于：测试环境低并发、局域网延迟低，粘包/半包极少出现；一上生产，网络抖动、设备性能波动，问题集中爆发。别等线上丢数据才想起来检查缓冲区消费逻辑。
