binary.read不能直接用于net.conn，因tcp是字节流而binary.read假设输入为完整数据包；必须先读包长、校验、io.readfull读满、再用bytes.newreader封装后解析。
binary.Read 不能直接在 net.Conn 上流式解析二进制协议——它不处理粘包、不识别边界、不校验长度，强行使用必然导致字段错位、io.ErrUnexpectedEOF 或静默读错值。真正能跑通的链路，必须把分包逻辑写死在业务之前。
为什么 binary.Read 直接读 net.Conn 必然失败
TCP 是字节流，没有“一包”的概念；binary.Read 却假设输入是完整、对齐、可随机定位的内存块。两者根本不在一个抽象层上。
- 常见现象：
magic字段读成0（实际数据从第 3 字节开始，但解析器从第 1 字节硬啃） -
pkgLen uint32被截成两半（前 2 字节在网络包尾，后 2 字节在下一个包头），binary.Read返回io.ErrUnexpectedEOF - 后续所有字段整体偏移 2 字节，
uint32变成0x00010000而非预期的256 - 错误不是发生在解析时，而是从第一次
binary.Read(conn, ...)就已注定
必须用 io.ReadFull 提取完整包体，不能用 io.Read
拿到包长后，必须保证读满指定字节数，否则后续所有解析都基于错误前提。
- 先用
binary.Read(conn, order, &pkgLen)读出长度字段（注意该字段自身也有字节序！） - 立刻校验：
if pkgLen == 0 || pkgLen > 1<code>MB→ 直接关闭连接，防恶意构造或越界分配 - 分配缓冲区：
data := make([]byte, pkgLen) - 关键一步：
io.ReadFull(conn, data)—— 它会阻塞直到填满data，或返回错误；而io.Read可能只读到部分就返回n ，后续全错位
拿到完整 []byte 后，别直接传给 binary.Read
把原始切片强转或直接传入，容易因底层底层数组复用、旧数据残留、或指针别名导致解析结果不稳定。
- 正确做法：用
bytes.NewReader(data)包一层，得到干净、隔离、可重置的io.Reader - 再调
binary.Read(reader, order, &v)，确保每次解析都是从头开始、无状态干扰 - 如果结构体含变长字段（如用户名），仍需在
data内部手动拆解：先读长度字段，再用io.ReadFull(bytes.NewReader(data[headerLen:]), nameBuf[:nameLen]) - 禁用
unsafe.Pointer强转：(*Header)(unsafe.Pointer(&data[0]))看似快，但结构体填充、对齐、GOARCH 差异会让它在不同环境行为不一致，Go 1.21+ 运行时可能 panic
结构体定义和字段解析最容易被忽略的三个硬约束
即使分包和读取都正确，binary.Read 仍会静默失败或 panic，只因结构体没按协议“刻”出来。
- 所有字段名必须首字母大写（导出）：
ID int32✅，id int32❌（后者被完全跳过，值保持零值） - 禁用
int/uint，改用int32、uint16等定长类型（避免 32/64 位平台差异） - 字节序必须与抓包 hex 严格一致：若抓包看到
00 00 01 00对应值256，协议就是大端 → 必须传binary.BigEndian；传LittleEndian会解出0x00010000（65536） -
string和[]byte字段会导致panic: invalid type—— 不是 bug，是设计限制；必须用[32]byte+bytes.TrimRight模拟字符串
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
