recv一次读不到完整包是因为TCP是字节流协议，只返回当前缓冲区数据，不按业务包边界分割；需用接收缓冲区累积数据，先检够4字节包头再ntohl解析长度，再检够全长后切包。
为什么 recv 一次读不到完整包？
因为 TCP 是字节流协议，recv 只保证返回「当前缓冲区里有的数据」，不关心业务上的「一个包」。你定义的包头含 4 字节长度字段，但网络可能分三批送达：2 字节 + 1 字节 + 剩余全部。这时候直接按固定长度解析包头会失败——读到的前 2 字节根本构不成有效 packet_length。
解决思路不是等「整包到达」，而是维护一个接收缓冲区（std::vector<uint8_t></uint8_t>），每次 recv 后追加数据，再循环检查是否能解析出完整包：
- 先检查缓冲区是否 ≥ 包头长度（比如 4 字节）；不够就继续收
- 够了就读出包头，解析出
payload_length - 再检查缓冲区总长是否 ≥
header_size + payload_length；不够就继续收 - 够了就切出完整包，从缓冲区前端移除对应字节数
如何安全提取包头里的长度字段？
别直接 reinterpret_cast 或 memcpy 到 uint32_t*——大小端不一致时结果错乱。例如服务端用大端写入，客户端小端机器直接读会把 0x0000000A 当成 167772160。
正确做法是用 ntohl()（网络序转主机序）或手动逐字节拼接：
立即学习“C++免费学习笔记（深入）”；
uint32_t len = (static_cast<uint32_t>(buf[0]) << 24) |
(static_cast<uint32_t>(buf[1]) << 16) |
(static_cast<uint32_t>(buf[2]) << 8) |
static_cast<uint32_t>(buf[3]);
如果协议明确要求大端（常见），且你确认运行环境支持 ntohl，那它更简洁；否则手写兼容性更强。注意：ntohl 输入是 uint32_t，需确保传入的是 4 字节无符号整数，不要传指针。
粘包处理中容易漏掉的边界情况
真实网络环境里，这些点一踩就卡死：
-
recv返回 0 表示对端关闭连接，此时缓冲区里若还有未解析完的残包，要按错误包处理，不能忽略 - 解析出的
payload_length为 0 是合法的（空载荷），但必须允许；若为负数或超大值（比如 > 10MB），要立即丢弃并清空缓冲区，防内存耗尽 - 缓冲区用
std::vector::erase(begin(), begin() + n)移除已处理数据，但频繁擦除头部性能差；建议改用环形缓冲区（boost::circular_buffer）或只移动读偏移量（read_pos），定期 compact - 多线程场景下，缓冲区必须加锁；但锁粒度别太大——只在 push_back 和 parse 循环处加，别把
recv也包进去
要不要用 MSG_WAITALL？
不要。这个 flag 看似能「让 recv 等够指定字节数再返回」，但它只对单次调用生效，且在非阻塞 socket 上直接失败，在阻塞 socket 上可能无限期挂起（比如对端崩溃、中间断网）。更糟的是，它无法解决粘包本质问题：你仍得自己管理缓冲区和包边界。真正可靠的方式只有「收→存→查→取」四步闭环。
另外，MSG_WAITALL 在部分系统（如 macOS）行为不一致，Windows 下甚至不支持。与其赌平台特性，不如把逻辑写清楚。
复杂点在于：包头长度本身也可能被拆开（比如 4 字节头被分成 1+3），而很多人只想到 payload 被拆，忘了头也会碎。这点一旦忽略，整个解析逻辑就崩在第一步。
