go的encoding/binary包只严格按指定字节序摊平或还原固定大小值，不自动猜端序、不处理填充、不支持变长字段；读不出数据主因是字节序错配或缓冲区不足，须用导出字段、定长类型、长度前缀处理变长内容，并先分包再解析。
Go 的 encoding/binary 不自动猜字节序、不处理填充、不支持变长字段——它只做一件事：按你指定的字节序，把固定大小的 Go 值“摊平”成字节，或反向还原。用错一个参数，读出来的值就全错。
binary.Read 读不出预期值？先查字节序和缓冲区长度
最常见的失败不是代码写错了，而是字节序 mismatch 或缓冲区不够长。
- Python
struct.pack('iih')默认小端 → Go 必须用binary.LittleEndian；若协议文档写>iih（大端），你就得换binary.BigEndian -
binary.Read不会跳过多余字节，也不会容忍少字节：读int32但传入只有 3 字节的[]byte，直接返回io.ErrUnexpectedEOF - 安全做法是先检查：
if len(buf) ，再用 <code>bytes.NewReader(buf)包一层传给binary.Read - 用
xxd -c 1 file.bin看原始 hex：若已知值是 256，文件里前 4 字节是00 00 01 00→ 大端；是00 01 00 00→ 小端
结构体字段必须导出且定长，否则 silent skip 或 panic
binary.Read 和 binary.Write 只访问首字母大写的导出字段，且对类型极其挑剔。
- 字段名小写（如
a int32）会被完全忽略，不报错也不读写 - 不能用
int、uint——它们平台相关，binary直接 panic；必须用int32、uint16等明确位宽类型 -
string、[]byte、map、interface{}全都不支持；含这些字段的 struct 传给binary.Write会 panic - 想存字符串？得手动拆：先写
uint16长度，再用w.Write([]byte(s))；读时反向操作
从文件或网络读取时，别用 io.Read，改用 io.ReadFull
io.Read 可能只读部分字节就返回 nil 错误，导致后续解析彻底错位。
-
binary.Read底层调用io.ReadFull，但它只在传入的io.Reader上做一次尝试；如果底层连接只返回 2 字节，它就卡住或报io.ErrUnexpectedEOF - 正确做法：对固定长度块（如 10 字节 record），先分配
buf := make([]byte, 10)，再调用io.ReadFull(r, buf)—— 它要么读满，要么明确报错 - 网络场景更需分包：协议头带
uint32包长字段，先用binary.Read(r, order, &pkgLen)提取长度，再io.ReadFull(r, data[:pkgLen])拿完整包 - 文件末尾易出问题：
io.ReadFull在 EOF 时返回io.ErrUnexpectedEOF（不是io.EOF），这是正常信号，表示数据不完整
binary.Write 性能敏感？避免在循环里反复调用
每次 binary.Write 都触发反射检查 + 类型判断 + 字节序转换，开销远高于直接拼 []byte。
- 高频写场景（如日志、批量序列化），优先用
bytes.Buffer或预分配[]byte手动写：binary.PutUint32(buf[0:], val) - 结构体写入没问题，但字段顺序必须和协议一字不差；加
_ [4]byte这类 padding 字段要显式声明，binary不会自动对齐 - 写入前可用
unsafe.Sizeof(Record{})校验结构体大小是否符合预期（比如int32+int32+int16=10） - 魔数（magic number）建议硬编码为
uint32(0x464C457F)而非字符串转，避免编码歧义
真正容易被忽略的点是：binary 包没有“容错”机制。它不校验 magic、不验证 CRC、不跳过未知字段——你给它什么字节，它就按什么规则解。一旦协议文档写错一个字节序或长度，整个解析链就崩了。所以实际项目中，建议在 binary.Read 后立刻校验关键字段（如魔数、版本号），而不是等到业务逻辑里才发现数据异常。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
