tcp粘包是协议特性而非bug，必须通过应用层定义消息边界来解决；推荐使用网络字节序的长度前缀法，分阶段读取并严格管理接收缓冲区。
直接说结论：TCP粘包不是bug，是协议特性；不加应用层协议规则，recv 读出来的永远是字节流，不是“消息”。你不能靠调大缓冲区、关Nagle、改recv参数来“解决”它——必须自己定义边界。
为什么 recv 一次读到的数据总对不上发送次数
TCP根本不认识你的“消息”。它只管把字节按序送到接收缓冲区，至于你发了 3 次 send，还是 1 次发了 300 字节，对内核来说没区别。常见现象包括：
- 客户端发了两段数据：
"LOGIN"和"USER=alice"，服务端recv一次拿到"LOGINUSER=alice"（粘包） - 客户端发了 2048 字节的 JSON，服务端第一次
recv只读到 1448 字节（半包），第二次才收到剩下 600 字节 -
recv返回值忽大忽小，且和业务逻辑里预设的包长完全不匹配
根本原因就三条：send 被 Nagle 合并、接收缓冲区积压、IP 层 MTU 分片重组。这些全在内核里发生，应用层无权干预。
长度前缀法怎么写才不崩
这是二进制协议最稳妥的方案：每个包开头放一个固定长度的整数字段（如 uint32_t），表示后续有效载荷字节数。关键不是“加前缀”，而是“分阶段读取 + 缓冲累积”。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须用
bytesAvailable()（Qt）或自己维护接收缓冲区（原生 socket）判断当前可读字节数，不能直接recv到固定大小数组里硬解 - 第一阶段：等够 4 字节（
sizeof(uint32_t)），再用QDataStream或memcpy提取长度值；若不足 4 字节就 return，等下次事件触发 - 第二阶段：检查缓冲区是否 ≥ 提取出的长度值；不够就继续等，够了才读出完整 payload
- 每次成功读完一包后，要把已消费的字节从缓冲区头部移除（比如用
QByteArray::mid()或std::vector::erase）
漏掉任一条件，比如跳过 bytesAvailable() 判断直接 read(4)，就会读到半个 uint32_t，解析出垃圾数值，后续全错。
定长包和分隔符什么时候能用
它们不是不能用，而是有明确适用边界，硬套反而更危险：
-
定长包只适合纯控制指令类场景，比如心跳包固定 8 字节、设备状态上报固定 64 字节；一旦业务数据长度浮动（如用户昵称从 3 字到 30 字），要么浪费带宽填空，要么要额外加截断/分片逻辑 -
分隔符（如"\r\n"）仅限文本协议，且要求业务数据本身绝不能出现该序列；如果传输的是 base64 图片或加密二进制，"\r\n"可能天然存在于数据中，导致提前截断 - 跨平台时注意字节序：
uint32_t前缀必须统一用网络字节序（htonl()发，ntohl()收），否则 x86 和 ARM 之间会解析失败
长度前缀法看似多写几行，但省去了转义、填充、长度校验等一堆边缘 case 处理，长期看代码更健壮、调试更直观。
最容易被忽略的点：缓冲区管理不是“读完就清空”，而是“按需消费、保留余量”。哪怕你用 std::vector<uint8_t></uint8_t> 自己攒数据，也要在每次成功解析一包后，只 erase 掉已处理的字节，而不是整个 clear——否则下个半包就丢了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
