binary.Read 读小端数据必须显式传 binary.LittleEndian，否则数值错误；参数需 io.Reader 和固定大小类型；结构体字段字节序须统一且全导出；手动用 binary.LittleEndian.Uint32 等更可控；需先分帧再读，避免粘包。
binary.Read 读小端字节序数据时必须传 binary.LittleEndian
Go 的 binary.Read 本身不默认任何字节序，它完全依赖你传入的 binary.ByteOrder 参数。常见错误是直接传 binary.BigEndian 或漏传——结果读出来数值全错，比如本该是 0x0100（小端表示 256），却解析成 1。
正确写法就是显式指定 binary.LittleEndian：
var val uint16 err := binary.Read(r, binary.LittleEndian, &val)
- 参数
r必须实现io.Reader接口（如*bytes.Reader、os.File、net.Conn） - 目标变量
val类型必须是固定大小的整数或浮点类型（int32、uint64、float32等），不能是int（平台相关） - 如果读取长度不足（比如只给了 2 字节却想读
uint32），binary.Read返回io.ErrUnexpectedEOF
读结构体字段时各字段字节序必须统一
Go 没有内置结构体字节序标注机制，binary.Read 对结构体是按字段顺序逐个读，并对每个字段单独应用你传入的 ByteOrder。这意味着：所有字段必须约定同一种字节序（通常是全小端），否则无法可靠解析。
例如这个结构体：
立即学习“go语言免费学习笔记（深入）”；
type Header struct {
Magic uint32
Length uint16
Flags uint8
}
用小端读取时，整个结构体二进制布局必须是：Magic（4 字节小端）+ Length（2 字节小端）+ Flags（1 字节，字节序无关）。
- 不能混用：比如
Magic大端 +Length小端 ——binary.Read不支持 per-field 字节序 - 结构体不能含指针、slice、map；否则
binary.Read会 panic 或静默失败 - 字段需导出（首字母大写），否则反射无法访问
替代方案：用 binary.LittleEndian.Uint32 等方法手动读更可控
当只需要读几个固定位置的值（比如协议头前 8 字节），比调用 binary.Read 更轻量、更不易出错的方式，是直接用 binary.LittleEndian 提供的原子方法：
b := make([]byte, 8) io.ReadFull(r, b) // 确保读满 magic := binary.LittleEndian.Uint32(b[:4]) length := binary.LittleEndian.Uint32(b[4:8])
- 避免了反射开销和结构体约束，适合高性能或协议解析场景
- 可精确控制偏移和长度，适合处理非对齐或嵌套二进制格式
- 注意：这些方法不检查输入切片长度，
b[:4]若实际只有 3 字节会 panic，务必先校验长度 - 对应函数名严格按类型命名：
Uint16、Int64、Uint32，别拼错
容易被忽略的坑：网络字节流可能带粘包，binary.Read 不自动分帧
binary.Read 是纯字节流读取器，它不会识别消息边界。如果你从 TCP 连接读小端数据，而对方发来的是多个拼接的消息（如两个 uint32 连续发送），binary.Read 会把第二个数的前两字节当作第一个数的后半部分，导致全部错乱。
- 解决方案不是换函数，而是先做分帧：用定长头、分隔符或 TLV 方式提取单条完整消息后再交给
binary.Read - 别依赖
bufio.Reader的ReadSlice直接喂给binary.Read，除非你确认切片长度刚好匹配目标类型 - 调试时可用
fmt.Printf("%x", b)打印原始字节，比猜数值更可靠
binary.Read。这几个点卡住，查半天也看不出哪行代码“逻辑不对”。 
