TCP粘包本质是协议无消息边界导致的字节流解析问题，必须通过自定义头部（含魔数、版本、校验和、长度）并分阶段读取+严格错误处理来解决。
Go 网络编程面试中，TCP 粘包问题不是“会不会用框架”的问题，而是“能不能在 net.Conn 底层写出健壮收发逻辑”的分水岭。不处理粘包，Read 返回的数据就不可信——你永远不知道一次 Read 拿到的是半个请求、两个请求，还是半个加一个半。
为什么 conn.Read 会读出“不完整”或“多余”的数据
TCP 是字节流协议，没有消息边界概念。内核和网卡驱动会按 MSS、Nagle 算法、延迟 ACK 等机制自动拼包或拆包。应用层看到的只是连续字节流，Read 只保证“至少读 1 字节（除非 EOF/err）”，不保证“读完一个业务消息”。常见现象包括：
- 客户端发了两条
["login", "logout"]，服务端一次Read收到"loginlogout"（粘包） - 客户端发了大消息（如 2MB 日志），服务端第一次
Read只拿到前 4096 字节（拆包） -
Read返回n=1024，但实际业务消息只有 300 字节，后面 724 字节是下一条消息开头（混合）
这不是 Go 的 bug，是 TCP 协议本性。所有语言写 TCP 都要面对它。
binary.Read 和 io.ReadFull 不能直接解决粘包
新手常误以为用 binary.Read(conn, binary.BigEndian, &header) 就能安全读头，但这是错的：binary.Read 内部调用 Read，仍可能只读到部分 header；io.ReadFull 虽能确保读满指定长度，但它不处理“读完 header 后，再按 bodyLen 读 body”这个两阶段流程，且对错误返回不区分 EOF 和临时错误（如 syscall.EAGAIN）。
正确做法是手动控制两次读取，并显式检查每次的 err：
headerBuf := make([]byte, 4)
_, err := io.ReadFull(conn, headerBuf) // 必须读满 4 字节
if err != nil {
return // 区分 io.EOF / net.ErrClosed / timeout 等
}
bodyLen := binary.BigEndian.Uint32(headerBuf)
bodyBuf := make([]byte, bodyLen)
_, err = io.ReadFull(conn, bodyBuf) // 必须读满 bodyLen 字节
if err != nil {
return
}
注意：io.ReadFull 返回 io.ErrUnexpectedEOF 表示连接提前断开，不是正常 EOF，需按异常处理。
固定长度方案只适合极简单场景，且容易踩内存坑
设 const msgLen = 1024，每次 Read 分配 1024 字节 buffer，看似简单，但有硬伤：
- 浪费带宽和内存：发 12 字节的 ping，也占满 1024 字节
- 无法处理超长消息：一旦业务消息 > 1024，必然截断或崩溃
- 容易误用
processData(buf)：必须用buf[:n]，否则把未读的旧数据也当新消息处理（n才是真实读取长度）
更隐蔽的坑是：如果连接断开时，Read 返回 n=0, err=io.EOF，但代码没检查 n==0 就直接 processData(buf[:n])，会导致 panic：切片长度为 0 的 buf[:0] 虽合法，但后续解析逻辑可能崩。
真正上线要用的消息协议必须带校验和与版本字段
工业级方案（如 gRPC、Kafka 协议）绝不止“头4字节长度”，还会包含：
- 魔数（Magic Number）：前 2 字节标识协议，避免脏数据误触发解析
- 版本号：支持协议升级，老服务可拒绝不兼容版本
- 校验和（CRC32 或 xxHash）：检测传输过程中的比特翻转
- 压缩标志位：决定 body 是否需解压
例如头部定义为：[2]byte Magic + [1]byte Version + [1]byte Flags + [4]byte BodyLen + [4]byte CRC32，共 12 字节。少任何一个字段，在高并发、长连接、跨机房网络环境下，都会导致静默数据错乱，排查成本极高。
粘包的本质不是“怎么读”，而是“怎么定义消息边界并验证它”。跳过校验和与魔数，等于裸奔。
