tcp粘包本质是其字节流无消息边界，接收端需依协议解析：先读定长包头（含payload_len字段，网络序），再按长度收全包体；须用累积缓冲区、禁用nagle、严格序列化发送。
粘包问题本质是 TCP 没有消息边界
Socket 用 TCP 传文件时，recv() 返回的字节数不等于你期望的“一个包”，可能一次读到多个包头+包体，也可能只读到半个包头——这不是 bug，是 TCP 流式特性的必然表现。C++ 里没现成的“自动拆包”函数，必须自己按协议解析包头来切分数据流。
包头必须固定长度且含有效载荷长度字段
常见错误是把包头设计成变长（比如用 \0 分隔），这会让解析逻辑复杂且易崩溃。正确做法是定义一个定长结构体，开头几个字节明确存 payload_len，比如：
struct FilePacketHeader {
uint32_t magic; // 校验用，如 0x46494C45 ('FILE')
uint32_t payload_len; // 真实文件数据长度，网络字节序
uint32_t checksum; // 可选
};
这样每次从缓冲区取 sizeof(FilePacketHeader) 字节就能拿到完整包头；再根据 payload_len 判断是否收齐整个包。
- 务必用
ntohl()转换payload_len，否则大小端不一致直接错乱 - 包头长度建议 12/16 字节整数倍，避免内存对齐干扰读取
- 不要在包头里放字符串或路径名——它们长度不可控，破坏定长前提
接收端需维护累积缓冲区并循环解析
不能每次 recv() 后就清空缓冲区。真实场景中，一个 recv() 可能只收到包头前 2 字节，下一次才补全包头，再下一次才收到部分 payload。所以必须：
- 用
std::vector<uint8_t></uint8_t>或std::string做接收缓冲区，持续追加 - 每次新数据到达后，检查缓冲区是否 ≥ 包头长度；若够，解析出
payload_len - 再检查缓冲区是否 ≥ 包头长度 +
payload_len；若够，提取完整包，从缓冲区头部移除已处理数据 - 若不够，等待下次
recv()，不阻塞、不丢弃、不重置缓冲区
典型错误是：收到 100 字节就急着 memcpy 解析，结果 payload_len 还没凑齐，解出来是随机值。
发送端必须严格按协议发包，且禁用 Nagle 算法
即使接收端逻辑完美，发送端一松懈就前功尽弃。关键点：
- 发送前先序列化包头（注意用
htonl()转换payload_len），再拼接 payload，整体调用send() - 在 socket 上设置
TCP_NODELAY：int nodelay = 1; setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &nodelay, sizeof(nodelay));，否则小包可能被内核合并 - 不要分两次调用
send()发包头和 payload——TCP 不保证两次 send 的数据在接收端保持分离
容易被忽略的是：某些平台（如 Windows）默认启用 Nagle，而 Linux 在高吞吐场景下也偶尔触发，不关掉的话，哪怕你发了 12 字节包头，也可能等几十毫秒才真正发出。
最麻烦的不是写解析逻辑，而是缓冲区管理边界条件：比如刚收完一个包，剩余数据恰好是下一个包的前 3 字节，此时要保留这 3 字节继续等待，而不是当成脏数据丢掉。这种“半包残留”状态必须显式跟踪，靠代码注释或变量命名（如 pending_buffer）强化意识。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
