TCP粘包不是bug，而是字节流协议的必然表现；recv一次可能拿到两条消息拼接的数据，因TCP不识别消息边界，只按序交付字节流，发送端多次send的数据可能被内核合并存于接收缓冲区，等待recv一次性读出。
TCP 粘包不是 bug，是字节流协议的必然表现；不处理就直接 recv 读缓冲区，解析逻辑必错。
为什么 recv 一次拿到的数据可能是两条消息拼在一起
TCP 不认识“消息”，只按字节流交付数据。发送端调两次 send，接收端一次 recv 完全可能拿到全部字节——因为内核把数据攒在接收缓冲区里等你来取。这不是网络异常，而是协议设计使然。
- Nagle 算法会合并小包（如连续发两个
"hello"，可能合成"hellohello"发出） - 接收端读得慢，多个包在
SO_RCVBUF里堆着，recv(1024)一把全捞出来 - MSS、MTU、延迟确认（Delayed ACK）都会影响分段时机，但最终都表现为：应用层看到的是一串无边界的字节
长度前缀法为什么是二进制协议首选
相比定长包（浪费带宽）和分隔符法（\n 出现在正文里就崩溃），长度前缀法在二进制场景下最可控、最易校验。
- 包头固定 4 字节（
uint32_t），大端序写入：htonl(len) - 必须先读够 4 字节，再根据该值读取后续 payload，不能跳过或假设
-
len值必须做上限检查（比如限制 ≤ 1MB），否则恶意长度会导致malloc失败或越界读 - 读取过程要支持增量解析：一次
recv可能只到 2 字节包头，下次才补全，不能丢弃已收部分
recv 返回值和缓冲区管理最容易踩的坑
新手常把 recv 当作“一定能读满指定长度”，结果在循环里反复覆盖缓冲区，或忽略返回值为 0（对端关闭）和 -1（错误）的情况。
-
recv返回值是实际收到字节数，可能 bufsize，也可能为 0（连接关闭） - 不要用
std::string直接拼接未校验的原始字节流——它内部append可能触发多次 realloc，且不保证内存连续 - 推荐用
std::vector管理接收缓冲区，并维护一个size_t offset表示当前已解析位置，避免拷贝 - 每次
recv后，要把新数据追加到缓冲区末尾，然后从offset开始扫描是否有完整帧，而不是清空重来
ASan 和 Wireshark 是定位粘包问题的两个关键工具
光看代码很难复现粘包，必须结合真实流量和内存行为验证。
- 用
tcpdump或 Wireshark 抓包，过滤 TCP 流，看发送端是否真发了多个独立 segment，还是被合并了 - 本地调试时开 AddressSanitizer（
-fsanitize=address），一旦长度字段被误读导致越界读写，立刻报错 - 写单元测试时，手动构造粘包输入：比如把两个合法帧的字节流拼成一整块，喂给解析器，验证它能否正确切分
真正难的不是实现长度前缀解析，而是在高并发下保持偏移量、缓冲区、回调之间的状态一致——任何一处没加锁或没原子更新，都会让粘包逻辑在多线程中悄悄失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
