binary.read 读 int32 错误是因为未显式指定字节序，默认 binary.bigendian 而数据实为小端；需用 hex.dump 确认原始字节布局，并传入 binary.littleendian 或 binary.bigendian。
为什么 binary.Read 读出来的 int32 总是错的？
因为没指定字节序，binary.Read 默认用 binary.BigEndian，但你的数据可能是小端（比如 x86 网络设备、某些嵌入式协议、Windows 二进制 dump）。直接读会导致高/低字节颠倒，数值完全不对。
- 检查协议文档或原始数据十六进制：如果
0x01 00 00 00本意是 1，那就是小端；如果是 16777216，才是大端 - 别猜，用
hex.Dump打印前 8 字节确认实际布局 - 必须显式传入
binary.LittleEndian或binary.BigEndian，不能依赖默认值 -
binary.Read第三个参数是io.Reader，第四个才是binary.ByteOrder—— 参数顺序容易写反
结构体里混用大小端字段怎么读？
Go 的 binary.Read 不支持单个 struct 内不同字段用不同字节序。你不能让第一个 uint16 用大端、第二个用小端。
- 拆开读：先读固定长度的字节到
[]byte，再用binary.BigEndian.Uint16()和binary.LittleEndian.Uint32()分别解析对应位置 - 或者定义多个小 struct，每个只含同字节序字段，分批
binary.Read - 避免在 struct tag 里幻想用
`binary:"big"`—— 标准库不支持这种 tag - 如果字段多且复杂，建议封装成方法，把字节偏移和字节序逻辑收拢，别散落在调用处
binary.Write 写出的数据对方收不到？
常见原因是字节序不一致，或者写完没 flush（尤其用 bytes.Buffer 时，它内部不自动 flush，但数据已写入）。
- 确认对方期望的字节序，并在
binary.Write中显式传入，例如：binary.Write(w, binary.LittleEndian, val) - 如果写入的是
bytes.Buffer，后续要用b.Bytes()或b.String()拿数据，不是靠 “写完就自动可用” - 写入
net.Conn时，binary.Write本身不保证原子发送 —— 它只是调用Write方法，网络层可能分包，需上层加长度头或定界符 - 注意
int类型：Go 中int长度平台相关（32 或 64 位），跨平台通信务必用int32/int64
性能敏感场景下，binary.Read/binary.Write 能否优化？
能，但代价是放弃部分安全性和可读性。标准库封装会做类型反射和接口转换，对高频小数据（如每秒万级心跳包）有可观开销。
立即学习“go语言免费学习笔记（深入）”；
- 直接用
binary.BigEndian.PutUint32(buf[0:], v)替代binary.Write，跳过 io.Writer 接口调用和 error 检查 - 预分配足够大的
[]byte，复用而非每次 new，避免 GC 压力 - 读取时用
binary.BigEndian.Uint32(data[0:])，前提是确保len(data) >= 4，否则 panic —— 这点必须自己守门 - 不要为了“看起来简洁”而用
unsafe.Slice强转 struct，一旦字段对齐或 padding 变化，二进制就不可靠
字节序不是“选一个就好”的配置项，它是协议契约的一部分。哪怕只差一个字节的顺序，整个 payload 就全错。调试时优先 hexdump 原始字节，而不是盯着 Go struct 猜。
