binary.read 直接读 net.conn 必然失败，因 tcp 是字节流而 binary.read 要求完整数据包；错误根源包括字节序不匹配、非导出字段被跳过、非定长类型导致 panic 或错位，且必须先解决粘包、校验长度、读满再解析。
binary.Read 直接读 net.Conn 必然失败，这不是写法问题，是协议层根本没对齐——TCP 是字节流，而它只认“刚好一包”的完整数据。
为什么 binary.Read 一用就返回 0 或极大随机数
几乎全是字节序（endianness）传错。Go 不检测、不提示、不自动适配：你传 binary.LittleEndian，它就按小端解；协议实际是大端（比如抓包看到前 4 字节是 00 00 01 00），结果 uint32 解出来是 65536 而不是 256。
- 抓包看原始 hex：
00 00 00 01→ 对应uint32 = 1→ 协议用大端 → 必须传binary.BigEndian -
01 00 00 00→ 小端 → 必须用binary.LittleEndian - Python 的
struct.pack('iih')默认小端，Go 端必须严格匹配 - 别靠“试”，直接查协议文档或抓包确认端序
结构体字段导出 + 定长类型 + 字节序对齐缺一不可
binary.Read 不猜、不兼容、不自动转换。它严格按你传的 order 和结构体定义来解码，错一点就全错。
- 字段名首字母小写（如
id int32）会被完全跳过，值保持零值，不报错也不警告 - 禁用
int/uint：它们在 32 位和 64 位平台长度不同；协议里写死的是int32或uint16，你就得用对应定长类型 -
string或[]byte字段会直接 panic："invalid type"；必须改用[32]byte这类定长数组 - 字段顺序必须和协议文档一字不差，错一位，后续全偏移
-
binary.Size(&s)可用来校验 struct 实际大小是否和协议一致
TCP 粘包必须在 binary.Read 之前解决
把 net.Conn 直接丢给 binary.Read，等于让解析器在流动字节流里“盲猜”包边界。常见错误包括魔数读成 0、长度字段被截半、io.ReadFull 死等。
- 先读协议头固定长度（如前 4 字节），用
binary.Read(r, order, &pkgLen)提取完整包长 - 立刻校验
pkgLen是否合理（如MB且>= 最小合法包长），超限直接断连 - 调用
io.ReadFull(r, data[:pkgLen])（不是Read）确保读满 - 拿到完整
data后，再用bytes.NewReader(data)交给binary.Read - 别信“协议文档说包长固定”——TCP 层不认这个，每条连接都可能粘包
变长字段必须手动拆解，不能依赖 binary.Read
binary.Read 对 []byte、string、map、interface{} 零支持。协议里任何非固定长度字段（用户名、JSON 载荷、TLV 子项），都必须拆成“长度前缀 + 内容”两步走。
- 先读长度字段（注意该字段自身也有字节序！），如
binary.Read(r, order, &nameLen) - 校验
nameLen是否越界（如if nameLen > 256 { return errors.New("name too long") }） - 复用预分配缓冲区：
io.ReadFull(r, nameBuf[:nameLen]) - 字符串需清理填充零：
string(bytes.TrimRight(nameBuf[:nameLen], "\x00")) - TLV 中 Length 字段本身可能是变长编码（如首字节高 2 位表示长度字节数），需按协议规则先解析长度字段再读值
真正容易被忽略的不是语法细节，而是控制流顺序：分包、校验、读满、再解析——这四步少一步，后面所有字段都会错位。尤其当协议含嵌套 TLV 或校验和时，顺序错一点，整个包就废了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
