tcp因是字节流协议无消息边界，send()发大数组必导致粘包或拆包；需用固定长度头部（如4字节）标识载荷长度，配合循环recv、缓冲区管理与字节序转换来可靠收发。
为什么send()发大数组会粘包或拆包
TCP 是字节流协议，不保留应用层的“消息边界”。你调用一次 send() 发 10MB 数组，内核可能分几十次把数据推到网络上；反过来，对方调用一次 recv() 可能收到前一条的尾部 + 当前消息的开头 —— 这就是粘包。根本原因不是你代码写错，而是 TCP 本就不保证“一次 send 对应一次 recv”。
关键判断：只要没自己定义消息边界，就一定会遇到粘包/拆包。别指望 send() 和 recv() 的调用次数对等。
用固定长度头部+有效载荷解决粘包
最常用、最可控的做法：每个消息开头加 4 字节（或 2/8 字节）表示后续数据长度。接收方先收够头，再按长度收正文。这样即使 recv() 多次返回零碎数据，也能拼出完整消息。
-
send()前先序列化：先发htonl(len)（确保网络字节序），再发实际数据指针 -
recv()分两阶段：第一阶段循环收满 4 字节头，用ntohl()转回主机序；第二阶段按该长度循环收完正文 - 别用
recv(..., MSG_WAITALL)试图“一次收全”——它在非阻塞 socket 下直接失败，阻塞 socket 下也受系统缓冲区和网络抖动影响，不可靠 - 每次
recv()返回值必须检查：等于 0 表示对端关闭，小于 0 且errno == EAGAIN/EWOULDBLOCK表示暂时无数据（非错误）
接收缓冲区里怎么处理半包和多包
真实场景中，一个 recv() 调用可能只收到消息前半段（半包），也可能一口气带出两个完整消息（多包），甚至半包+整包+半包。不能假设每次只来一个消息。
- 维护一个接收缓冲区（如
std::vector<char></char>），把每次recv()的数据追加进去 - 循环检查缓冲区：如果够 4 字节头，解析出
len；如果缓冲区剩余字节数 ≥len + 4，就取出完整消息（跳过头，截取len字节），并从缓冲区头部移除已处理部分 - 移除时用
erase(begin(), begin() + processed_size)，别用下标赋值覆盖——容易漏掉中间残留 - 缓冲区要设上限（比如 64MB），防止恶意客户端发超长 length 导致 OOM
C++ 实现时容易踩的坑
很多问题不是逻辑错，而是类型/字节序/生命周期搞混了：
- 发送长度时用
uint32_t，但误传sizeof(int)—— 在某些平台int是 2 字节，导致接收方读错头 - 用
std::string存二进制数据（比如图片、加密数据），却调用c_str()或用+拼接 ——std::string内部不保证以\0结尾，且c_str()可能截断二进制中的\0 - 把
recv()缓冲区声明为局部数组（如char buf[65536]），然后传给异步回调 —— 回调执行时栈已销毁，读到的是野数据 - 没处理
send()返回值：它可能只发出部分字节，尤其在高负载或非阻塞 socket 下，必须用循环补发剩余部分
复杂点在于：粘包逻辑本身简单，但要把长度解析、缓冲区管理、错误恢复、内存安全全揉进一个稳定运行的 socket 循环里，任何一环松动都会导致后续所有消息错位。最容易被忽略的是 recv 缓冲区的“游标管理”——不是收到多少就清多少，而是必须严格按消息边界切片清理。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
