binary.Read必须显式指定binary.BigEndian或binary.LittleEndian，传nil、漏写或错用均panic；它不自动推断字节序，也不兼容协议差异，读取时须严格匹配协议约定的大端或小端格式。
binary.Read 必须显式指定字节序，不传或传错就出错——它不会猜、不兼容、不 fallback。
binary.Read 第二个参数必须是 binary.BigEndian 或 binary.LittleEndian
这个参数类型是 binary.ByteOrder，只有两个合法值：binary.BigEndian 和 binary.LittleEndian。传 nil、传 0、漏写，都会 panic 报 panic: nil ByteOrder。
- 网络协议（如 TCP/IP 头、PNG 文件头）基本用大端 → 选
binary.BigEndian - x86/x64 上的本地二进制数据、Windows API、多数 C 程序序列化结果倾向小端 → 选
binary.LittleEndian -
binary.NativeEndian是 Go 1.19+ 加入的，但它只是当前 CPU 的原生序，**不能替代协议约定**；比如 ARM64 可能是小端，但你的协议文档写明“时间戳字段为大端”，那就得硬写binary.BigEndian
读结构体时字段顺序和大小必须和二进制流完全对齐
binary.Read 按 struct 字段声明顺序、类型原生大小逐字节拷贝，不做 padding 补齐，也不跳过未导出字段。
- 所有字段必须首字母大写（导出），否则反射读不到，值保持零值
- 不能用
int/uint—— 它们长度平台相关，binary.Read直接拒绝，报binary: invalid type int；必须用int32、uint64等固定宽度类型 - struct 里有
byte后跟uint32，binary.Read 就按 1 + 4 = 5 字节连续读；如果协议里这俩之间有 3 字节 padding，你得手动跳过，或用_ [3]byte显式占位 - 字符串、slice、map 不支持直接读；变长字符串必须先读长度字段（如
uint16），再用buf[offset:offset+length]切片取内容
字节序不匹配时不会报“字节序错误”，只会读出错误数值
这是最隐蔽也最常踩的坑：binary.Read 返回 nil 错误，但数值明显不对。比如协议规定前 4 字节是 uint32 长度字段，实际值应为 0x0000000A（即 10），你却用小端读，就会得到 0x0A000000（167772160）。
立即学习“go语言免费学习笔记（深入）”；
- 典型现象：
io.ErrUnexpectedEOF往往不是数据真截断了，而是字节序错导致解析偏移错乱，后续字段长度计算全崩 - 调试技巧：用
xxd -c 1 file.bin | head -n 4看原始 hex，对照协议文档中已知值（如魔数0x474E5089）判断该用哪种序 - 别依赖
runtime.GOARCH或unsafe.Sizeof推断字节序——x86_64 是小端，不代表协议就是小端
混合字节序字段必须分步读，不能靠 struct 一把梭
binary.Read 不支持为 struct 中不同字段指定不同字节序。如果协议里 header.len 是小端 uint16，header.ts 是大端 float64，你就没法用一行 binary.Read(r, order, &h) 解完。
- 正确做法是分步：
binary.Read(r, binary.LittleEndian, &h.Len)→ 手动读 8 字节到uint64→binary.Read(r, binary.BigEndian, &tsBits)→h.Ts = math.Float64frombits(tsBits) - 不要试图在 struct tag 里加
binary:"big"—— 标准库根本不识别这个 tag，反射拿到也没用 - 如果协议强制混合字节序且无法推动统一，建议封装一个专用解码器，把每段偏移、类型、字节序都写死，避免逻辑散落在各处
最易被忽略的一点：binary.Read 对切片（[]byte）和数组（[N]byte）的处理完全不同——前者只拷贝长度，不涉及字节序；后者按元素类型逐个解码，每个元素都走一遍你传的 order。别以为给个 [4]byte 字段传 binary.LittleEndian 就能自动翻转整个数组，它只是确保每个 byte 单独读取时行为一致（其实 byte 没字节序，所以这一步纯冗余）。
