binary.write 和 binary.read 不默认使用任何字节序，必须显式传入 binary.bigendian 或 binary.littleendian，否则 panic；它们不自动推断、不依赖 cpu 字节序，完全由用户指定。
binary.Write 和 binary.Read 默认使用什么字节序
它们本身不默认用某一种字节序，而是**完全依赖你传入的 binary.ByteOrder 实现**。没传就 panic，不会自动猜。常见选择是 binary.BigEndian 或 binary.LittleEndian，二者都是预定义的全局变量，直接用就行。
容易踩的坑：误以为 binary.Write 会按本地 CPU 字节序自动处理——它不会。Go 的 binary 包是纯协议层抽象，和运行时环境无关。
如何把 int32 转成大端字节序列并写入 []byte
核心是用 bytes.Buffer 或直接分配字节数组，再调用 binary.Write。注意目标切片必须有足够容量（4 字节），且顺序由你指定的 ByteOrder 决定。
buf := make([]byte, 4)
err := binary.Write(bytes.NewBuffer(buf[:0]), binary.BigEndian, int32(0x12345678))
// buf 现在是 []byte{0x12, 0x34, 0x56, 0x78}
- 别直接传
buf给Write：它需要io.Writer，不是[]byte - 用
bytes.NewBuffer(buf[:0])是为了复用底层数组，避免额外分配 - 如果目标是小端，把
binary.BigEndian换成binary.LittleEndian即可
读取字节切片时字节序不匹配会导致什么错误
不会报“字节序错误”，而是读出完全错误的数值，比如把 []byte{0x00, 0x00, 0x00, 0x01} 用小端读成 int32(1)，但用大端读就是 int32(16777216)。调试时很难一眼发现，尤其当数据来自网络或文件且文档没明确标注字节序时。
建议做法：
- 始终在读写两端显式约定并硬编码字节序，不要依赖“系统默认”
- 对关键字段加注释，例如：
// wire format: uint32 in little-endian - 单元测试里用已知值双向验证：
Write → []byte → Read，确保还原一致
struct 字段批量序列化时要注意字段对齐和填充
binary.Write 对 struct 是逐字段线性写入，**不做内存对齐处理，也不跳过未导出字段**。只要字段是导出的（首字母大写）且类型支持（基础类型、数组、嵌套 struct 等），就会按声明顺序写入。
问题在于：如果你的 struct 定义里有 int16 后跟 int64，而底层内存因对齐插入了 padding 字节，binary.Write 不会写那些 padding——它只写字段值本身。所以 struct 必须“自然紧凑”，否则与 C 或其他语言通信时会错位。
稳妥做法：
- 用
struct{ a uint32; b uint16; _ [2]byte }显式补零，而不是依赖编译器填充 - 避免混用不同大小的基础类型，优先用固定宽类型如
uint32而非int - 如果必须兼容 C struct，用
//go:notinheap或unsafe.Sizeof校验字段偏移是否符合预期
