binary.read不能直接读net.conn，因不处理粘包、不校验字节序、忽略未导出字段；安全做法是先分包、对齐字节序、定义全大写字段的定长结构体，并用io.readfull配合bytes.newreader解析。
binary.Read 不能直接读 net.Conn，否则 90% 概率错位或 panic——它不处理粘包、不校验字节序、不跳过未导出字段，只机械搬运字节。真正可用的私有协议封装，必须先做三件事：分包、对齐字节序、定义可序列化的结构体。
为什么 binary.Read 读出来的字段全是 0 或乱码
最常见原因就两个：字段没导出、字节序传错了。Go 不报错，只静默跳过小写字段（如 id int32），也不校验你传的 binary.LittleEndian 是否匹配协议原始 hex。
- 抓包看前 4 字节：若为
00 00 01 00→ 协议是大端 → 必须传binary.BigEndian - 若为
01 00 00 00→ 小端 → 必须传binary.LittleEndian - 结构体所有字段名必须首字母大写（如
ID int32），小写字段被完全忽略 - 禁用
int/uint，改用int32、uint16等定长类型，避免跨平台长度不一致 - 用
unsafe.Sizeof检查 struct 实际大小，确认和协议文档中字节数完全一致
如何安全处理 TCP 粘包再交给 binary.Read
binary.Read 不知道包边界，把 net.Conn 直接丢给它，等于让解析器在流动字节流里盲猜——一次 Read 可能跨两个包，也可能只读半个 header。
- 协议头前 4 字节必须为总包长（推荐
uint32），先用binary.Read(conn, order, &pkgLen)提取 - 立刻校验
pkgLen是否合理：比如pkgLen MB，超限直接断连防攻击 - 分配
data := make([]byte, pkgLen)，再调io.ReadFull(conn, data)—— 注意是ReadFull，不是Read - 拿到完整包后，用
bytes.NewReader(data)封装，再传给binary.Read解析内部字段
struct 里怎么放字符串和变长字段
binary.Read 遇到 string 或 []byte 会直接 panic："invalid type"。这不是 bug，是设计约束。协议里任何非固定长度的内容，都得靠“长度前缀 + 内容”两步走。
- 协议头预留一个
uint16或uint32字段表示后续内容长度 - 先用
binary.Read(r, order, &length)提取长度值（注意该长度字段自身也有字节序！） - 立刻校验
length是否合理（如 ≤ 1024），防恶意构造超长字段 - 再用
io.ReadFull(r, buf[:length])读满指定字节数（不能用io.Read，否则可能只读一半） - 如果内容是字符串，记得用
bytes.TrimRight(buf[:length], "\x00")去掉 C 风格填充零，再转string()
最容易被忽略的是：字段导出状态和字节序必须与抓包 hex 严格一致，差一位，整个 struct 后续字段全偏移；而 io.ReadFull 的缺失，会让粘包问题在高并发下随机复现，极难定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
