binary.read/write 是字节搬运工，失败主因是字节序错、字段未导出、内存对齐偏差和 tcp 粘包；struct 字段须首字母大写、顺序与协议一致、禁用 string/slice、长度字段需校验且字节序匹配、必须处理粘包。
binary.Read 和 binary.Write 不是语言学习工具，也不是协议框架——它们只是字节搬运工。想靠写几个 struct 就跑通二进制通信，90% 的失败发生在字节序、字段导出、内存对齐或 TCP 粘包这四点上。别从“学 Go 语言”开始，直接从“读错一个 uint32”入手。
struct 字段为什么读出来全是零
不是代码没执行，是 binary.Read 静默跳过了所有小写字母开头的字段：id int32、name string 这类字段根本不会被赋值，也不报错，结果就是 struct 里全是零值。
- 所有参与编解码的字段名必须首字母大写，比如
ID int32、NameLen uint16 - 嵌套 struct 里的字段也得导出，不能只导出外层
- 用
unsafe.Sizeof检查 struct 实际大小，确认和协议文档一致（比如int在 64 位系统占 8 字节，但协议可能只要 4 字节int32） -
json:或binary:tag 全无效，binary.Read完全不看它们
为什么读出来的数值总是错的
抓包看到前 4 字节是 00 00 01 00，对应 uint32 值应为 256，但用 binary.LittleEndian 读出来是 0x00010000（65536）——这不是 bug，是你传的字节序和协议不匹配。
- 协议文档写“网络字节序”＝大端，就用
binary.BigEndian；写“x86 主机序”＝小端，就用binary.LittleEndian - 别凭感觉选，用
hexdump -C或 Wireshark 看真实 wire bytes 再比对 - 长度字段（如
NameLen uint16）自身也有字节序，必须和协议一致 - 字段声明顺序必须和协议字节布局完全一致，调换两个字段，后续全部偏移
含 string 或 []byte 的 struct 一读就 panic
binary.Read 遇到 string、[]byte、map 会直接 panic: invalid type。这不是缺陷，是设计契约：它只处理定长原始类型。
- 固定长度字符串字段必须声明为
[32]byte，读完用bytes.TrimRight(name[:], "\x00")去零再转string() - 真正变长内容（如 UTF-8 用户名）必须带长度前缀：先
binary.Read(r, order, &nameLen)，再io.ReadFull(r, nameBuf[:nameLen]) - 长度字段本身要校验：
if nameLen > 1024 { return errors.New("name too long") } - 别把整个 struct 丢给
binary.Write，尤其含 slice 时——手动分字段写更可控，也方便插校验和
TCP 粘包导致 binary.Read 解析错位
直接把 net.Conn 当 io.Reader 传给 binary.Read，等于让它在流动字节流里盲猜包边界。一次 Read 可能跨两个包，也可能只读半个 header，魔数错位、长度字段被截断，后续全乱。
- 协议头前 4 字节必须是包总长（
uint32），先binary.Read(r, order, &pkgLen)提取 - 立刻校验：
if pkgLen == 0 || pkgLen > 1024*1024（防内存耗尽攻击） - 分配
data := make([]byte, pkgLen)，严格用io.ReadFull(r, data)（不是io.Read） - 拿到完整包后，用
bytes.NewReader(data)包一层，再交给binary.Read解析内部字段
io.ReadFull 的错误处理——它返回 io.ErrUnexpectedEOF 时，往往意味着连接提前断开或对方发包异常，不是解析逻辑问题。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
