binary.Read在net.Conn上失败主因是未处理TCP分包边界，须先用长度字段提取完整包体，再经bytes.NewReader封装后解析，否则必读错。
Go 里 binary.Read 解析二进制流失败，90% 是因为没处理好分包边界——它根本不认识“一包数据”从哪开始、到哪结束，只管按顺序啃字节。
binary.Read 为什么总在 net.Conn 上 panic 或读错值
直接把 net.Conn 当作 io.Reader 传给 binary.Read，等于让解析器在高速公路上闭眼开车：TCP 是无边界的字节流，binary.Read 却假设输入是“刚好一包”的完整内存块。常见现象包括：
-
io.ErrUnexpectedEOF：读到一半包就断了，比如长度字段被截成两半 - 魔数（magic）字段为
0或乱码：实际数据从第 3 字节开始，但解析器从第 1 字节硬读 - 后续所有字段全部偏移：一个
uint32字段读成0x00010000而不是预期的256，本质是起始位置错了
根本原因不是代码写错，而是没做前置分包——你得先从流里“抠出”完整包体，再喂给 binary.Read。
协议头必须带长度字段，且要校验范围
标准做法是协议头前 4 字节固定为总包长（uint32），这步不能省，也不能靠猜：
立即学习“go语言免费学习笔记（深入）”；
- 先用
binary.Read(conn, order, &pkgLen)提取长度值（注意该长度字段自身也有字节序！） - 立刻校验：
if pkgLen == 0 || pkgLen > 1<code>MB</code>→ 直接断连，防恶意构造或解析失控 - 分配缓冲区：
data := make([]byte, pkgLen)，然后必须用io.ReadFull(conn, data)，不是io.Read
io.ReadFull 是关键：它保证读满 pkgLen 字节，否则返回错误；而 io.Read 可能只读到一部分就返回，导致后续解析全错位。
拿到完整包后，别直接用原缓冲区调 binary.Read
拿到 data []byte 后，别把它当原始内存块强转或切片传给 binary.Read。正确链路是：
- 用
bytes.NewReader(data)包一层，得到干净、可重置的io.Reader - 再传给
binary.Read(reader, order, &structVal)—— 这样能避免底层缓冲区复用时旧数据干扰 - 如果结构体含变长字段（如用户名），仍需在包内再拆解：先读长度字段，再用
io.ReadFull读对应字节数
特别注意：binary.Read 完全无视 struct tag（json:、binary: 等），只认字段导出状态、声明顺序和定长类型。小写字母开头的字段（如 id int32）会被静默跳过，不报错也不赋值。
边界处理最易被忽略的细节
真正卡住人的往往不是大逻辑，而是这几个点：
- 长度字段自身的字节序必须和协议一致——抓包看前 4 字节是
00 00 01 00？那是大端；是00 01 00 00？那就是小端，别凭平台直觉选 - 用
unsafe.Sizeof(structVal)核对结构体实际大小，必须和协议文档标称字节数完全一致（int在 32/64 位系统长度不同，必须用int32） - 读完
io.Reader.Read(buf)后，永远用buf[:n]截取有效数据，别扫描\x00或其他字节判断终止——二进制数据里\x00是合法内容，不是结束符
分包不是加个函数就完事，它是整个二进制协议可靠性的第一道闸门。越想绕过它图省事，后面 debug 越像在迷宫里找出口。
