Go中struct转二进制必须手动控制字段偏移，因encoding/binary不自动处理对齐、padding及复杂类型（如string/slice），需预分配字节切片并用PutXXX函数按协议顺序精确写入各字段。
struct 转二进制必须手动控制字段偏移
Go 没有类似 Python struct.pack 的格式字符串语法，encoding/binary 不会自动解析结构体字段顺序或对齐。你不能直接把 struct 传给 binary.Write 就完事——除非该 struct 所有字段都是固定大小、无 padding，且你明确接受 Go 编译器决定的内存布局（这通常不可靠）。
正确做法是：预分配字节切片，按需用 binary.LittleEndian.PutUint32、binary.BigEndian.PutInt16 等函数写入每个字段到指定偏移位置。
- 字段顺序必须和协议/文件规范严格一致，比如
int32+int16+uint8就得按这个顺序写，不能依赖 struct 定义顺序 - struct 中若有指针、slice、map、string 字段，它们本身不参与二进制序列化——只写其 header（如 len/cap），不是你想要的“内容”
- 哪怕 struct 只含
int32和int16，Go 编译器也可能插入 padding 字节（尤其在字段跨 4/8 字节边界时），直接unsafe.Sizeof或reflect获取大小并拷贝会出错
binary.Write 适合单字段流式写入，不适合多字段精确布局
binary.Write 是方便的，但它逐个写入，不保证字段间无间隙，也不提供偏移控制。它适合写一串同类型值（如 []int32），或简单协议中“一个字段接一个字段”的场景。
示例中常见错误是这样写：
立即学习“go语言免费学习笔记（深入）”；
err := binary.Write(w, binary.LittleEndian, myStruct.FieldA) err = binary.Write(w, binary.LittleEndian, myStruct.FieldB)
问题在于：Write 每次调用都可能触发底层 buffer flush 或 syscall write，性能差；更重要的是，你无法控制 FieldA 和 FieldB 在文件中是否紧邻——如果 w 是 bytes.Buffer 还好，但如果是 *os.File，中间可能被其他 goroutine 并发写入干扰（虽罕见但非原子）。
- 真正需要精确布局（如网络包头、磁盘文件格式）时，必须预分配
buf := make([]byte, totalSize)，再用PutXXX写入各段 -
binary.Write对interface{}的支持有限：它能处理基本类型、数组、结构体（但仅限导出字段+无 padding），一旦 struct 含 slice/string，就会 panic 或写入垃圾 - 写入失败时，
binary.Write返回 error，但已写入的部分不会回滚——你得自己做事务封装或重试逻辑
string 和 []byte 字段要显式编码，不能直接写入
struct 中的 string 字段本质是头信息（指针+长度），直接写进二进制文件只会保存这两个机器地址相关的 uint64，毫无可移植性。同样，[]byte 字段也是头信息，不是底层数组内容。
正确做法取决于协议需求：
- 若协议要求固定长度字符串（如 32 字节用户名），用
[32]byte字段，再用copy(buf[offset:], []byte(myStr))填充，并手动补零 - 若要求带长度前缀的变长字符串，先写
uint16长度，再写内容字节——注意长度字段本身也要用PutUint16控制字节序 - 若字段是
[]byte，同样先写长度（如uint32），再写数据；避免用len(s)直接当 int 写，因为len返回 int，而协议通常指定为 uint32 - 千万别用
unsafe.String或(*[n]byte)(unsafe.Pointer(&s))强转 string——这依赖内存布局，跨平台/跨 Go 版本极易崩溃
读取时必须与写入严格镜像，否则字节错位
写入用了 LittleEndian.PutUint32(buf[0:4], x)，读取就必须用 binary.LittleEndian.Uint32(buf[0:4])。任何一处字节序、字段长度、偏移量不匹配，都会导致后续所有字段解析错乱——而且往往不报错，只是数值荒谬（比如时间戳变成负数、ID 变成极大值）。
容易忽略的点：
- 读取
int16时，若原始写入是uint16，用int16()强转会出错；反之亦然。协议文档必须明确是有符号还是无符号 - 文件开头若有 magic number 或版本号，务必先校验再继续读，否则错位解析可能一路错到底
- 读取变长字段后，记得更新当前偏移量（如
offset += 2 + uint32Len），别硬编码下一段起始位置 - 用
io.ReadFull替代file.Read，确保读够指定字节数；否则遇到 EOF 时只读了部分字段，binary函数会 panic
最麻烦的不是写，是保持读写两端对同一个 struct 定义的解释完全一致——字段增删、类型变更、注释变动，都得同步更新二进制序列化逻辑，稍有遗漏就是静默数据损坏。
