Go中binary.Read/Write必须显式指定BigEndian或LittleEndian，不可省略或传nil；struct直读写会忽略padding导致错位，应拆字段逐个处理。
Go 里没有自动字节序推断，binary.Read 和 binary.Write 必须显式传 binary.BigEndian 或 binary.LittleEndian，错一个就解析失败。
binary.Read / binary.Write 的字节序参数不能省略或传 nil
这两个函数第二个参数必须是实现了 binary.ByteOrder 接口的值，只有两个合法选项：binary.BigEndian 和 binary.LittleEndian。传 nil 会 panic：
panic: nil ByteOrder
- 别写
binary.Write(w, nil, x)—— 这是常见手误 - 协议规定用大端（比如网络协议、PNG、ELF），就固定用
binary.BigEndian；别试图根据runtime.GOARCH动态选 - 建议提成常量：
const order = binary.BigEndian，后续统一用order，避免散落硬编码
PutUintXX 和 UintXX 系列函数更适合手动控制偏移
当你需要往一个已分配的 []byte 特定位置写入或读取时，binary.BigEndian.PutUint32(dst, v) 比 binary.Write 更直接、更安全：
立即学习“go语言免费学习笔记（深入）”；
-
PutUint32要求len(dst) >= 4，否则 panic；Uint32同理，要求输入切片至少 4 字节 - 它不依赖
io.Reader/Writer，也不涉及缓冲区管理，适合构造报文头、序列化固定结构体字段 - 示例：
binary.BigEndian.PutUint16(data, 0x1011)写前两字节；binary.BigEndian.PutUint32(data[2:], 0x12345678)写后四字节
struct 直接读写极易因 padding 导致错位
Go 的 binary.Read/binary.Write 对 struct 是按字段声明顺序 + 原生大小拼接，**完全忽略内存对齐和 padding**：
- 定义
type Header struct { Magic uint16; Len uint32 }，在 64 位系统上Len前可能有 2 字节 padding，但binary.Write不会跳过它，也不会补它 → 实际写入 6 字节，但内存布局 ≠ 协议要求的紧凑 6 字节 - 结果：下游解析时字段全偏移，比如
Len读成Magic的高位 + 部分填充字节 - 正确做法只有两种：拆字段逐个读写（推荐），或用
unsafe.Sizeof+reflect强制紧凑布局（不推荐，可移植性差）
读取失败优先排查字节序和长度，不是数据损坏
遇到 io.ErrUnexpectedEOF 或数值明显异常（如 0x00000001 变成 0x01000000），大概率不是数据丢了，而是：
- 字节序反了：用
LittleEndian读了本该用BigEndian写的数据 - 起始偏移错了：比如从
buf[1:]开始读uint32，但没意识到第一个字节是 magic - 切片长度不足：读
uint32前没检查len(buf) >= 4 - 安全做法：先用
binary.Size(&x)算目标类型所需字节数，再用bytes.NewReader包一层，让binary.Read自动处理边界
最麻烦的不是选错字节序，而是混用 —— 比如协议明确要求大端，你某处用了 LittleEndian.PutUint16，其他地方又用 BigEndian，这种错误不会编译报错，但会在某个特定 payload 上突然翻车，且极难复现。
