tcp是字节流协议，不保证消息边界，导致读取时出现黏包或丢包；根本原因是缺乏协议头定义长度，需用固定头部（如4字节大端长度）+载荷方式解决。
为什么 net.Conn 读出来的数据会“粘”在一起或“少一段”
因为 TCP 是字节流协议，不保证应用层消息边界。你调用一次 conn.Write() 发一个包，对方 conn.Read() 可能分多次收到，也可能把两次 Write() 合并成一次读到——这就是黏包；反过来，如果对方没等完整包就提前解析，或者网络丢帧、缓冲区溢出，就出现丢包。
这不是 Go 的 bug，也不是你的代码写错了，而是所有基于 TCP 的自定义协议都必须面对的基础问题。
- 常见错误现象：
Read()返回的n比预期小，但err == nil；解析 JSON 或二进制结构体时 panic：invalid character / unexpected EOF - 根本原因：没有协议头约定长度，接收方无法判断“一整条消息”在哪里结束
- 别指望
bufio.Scanner或bufio.Reader.ReadString('\n')能解决——它们只适合文本协议，且对二进制或含 \0 的数据完全失效
怎么设计一个靠谱的协议头（Go 实现）
最常用的是「固定长度头部 + 变长载荷」：前 4 字节存整个包长度（含头），接收方先读够 4 字节，再按该长度读后续内容。这个方案简单、无歧义、兼容性强。
Go 中直接用 binary.BigEndian.PutUint32() 和 binary.BigEndian.Uint32() 处理，别手写位移，大小端不一致会直接错乱。
立即学习“go语言免费学习笔记（深入）”；
- 头部字段建议只保留必要信息：总长度（
uint32）、版本号（uint8）、类型（uint8），避免过度设计 - 总长度字段必须包含头部自身（比如 4 字节长度 + 2 字节类型 = 总长至少 6），否则接收方无法知道要不要继续读
- 不要用小端序（
LittleEndian），除非客户端全是 x86 Windows 且明确约定了——跨平台时极易踩坑 - 示例打包逻辑：
buf := make([]byte, 4+len(payload)) binary.BigEndian.PutUint32(buf[:4], uint32(4+len(payload))) copy(buf[4:], payload) conn.Write(buf)
接收端如何安全读完一个完整包（防阻塞 + 防崩溃）
不能直接 conn.Read() 一次了事，得拆成两步：先读头，再读体；每步都要检查 n 和 err，尤其注意 io.EOF 和 io.ErrUnexpectedEOF 的区别。
- 读头部时，如果
n 且 <code>err == nil，说明数据还没来全，得循环读直到凑够 4 字节（用io.ReadFull()最省心） - 读载荷时，同样用
io.ReadFull(conn, payloadBuf)，它会自动重试直到填满或返回真实错误 - 千万别用
conn.SetReadDeadline()简单粗暴设个 5 秒——网络抖动时可能误杀正常连接；应按阶段设：头读取 1s，体读取按长度估算（比如每 KB 10ms） - 如果
io.ReadFull()返回io.EOF，代表连接已关闭，不是丢包，直接退出即可；返回io.ErrUnexpectedEOF才是真丢包，需记录日志并断连
为什么不用 gob 或 json 直接序列化
它们本身不带长度头，也不处理 TCP 流粘连。你 gob.NewEncoder(conn).Encode(msg) 发出去，对方 gob.NewDecoder(conn).Decode(&msg) 会一直卡在读头，因为 gob 协议头也是变长的，且依赖底层流状态。
-
json.Decoder的Decode()方法内部会尝试读一个完整的 JSON 值，但遇到黏包时可能把下一条的开头当成本条结尾，导致解析失败或错位 - 性能上，gob/json 都有运行时反射开销，而二进制协议头 +
binary.Read()是零分配、纯内存操作 - 真正需要兼容多语言时，用
protobuf+ 自定义帧头（如 length-delimited）更稳妥，而不是依赖 Go 特有编码
协议头设计最易被忽略的点：没预留扩展位、长度字段没校验上限、没考虑连接复用时的中间状态残留。上线前一定用 nc 手动发畸形包（比如头里写个 2GB 长度）测服务是否 panic 或 hang 住。
