binary.write 写入结构体 panic 是因只支持基础类型、数组、切片或实现 binarymarshaler 的类型；含 slice/map/指针/interface{} 的 struct 必须手动实现 marshalbinary 或分字段写。
binary.Write 写入结构体时为什么 panic: binary.Write: invalid type
因为 binary.Write 只接受基础类型（int32、float64）、数组、切片（元素必须是可序列化的）或满足 encoding.BinaryMarshaler 接口的自定义类型。直接传 struct 会报这个错。
- 最简解决：用
unsafe.Sizeof+unsafe.Offsetof手动布局字段，或改用binary.Write分字段写（推荐） - 别偷懒写
binary.Write(w, order, &myStruct)—— 地址传递不等于可序列化 - 如果结构体字段含 slice、map、指针、interface{}，必须自己实现
MarshalBinary()方法
读取二进制流时字节序错误导致数值全乱
Go 的 binary.Read 和 binary.Write 默认不关心平台字节序，你传什么 binary.ByteOrder，它就用什么。x86 是小端，网络协议/文件格式常要求大端（binary.BigEndian），混用就出事。
- 确认协议规范：TCP/IP 头部、PNG 文件头、自定义协议文档里写的 endianness 是哪一种
- 统一用
binary.BigEndian或binary.LittleEndian，别依赖runtime.GOARCH - 调试时打印原始字节：
fmt.Printf("% x", buf)，对照十六进制预期值比对前 4 字节
从 io.Reader 流式解析不定长二进制包失败
binary.Read 是阻塞式读取固定长度，遇到变长字段（比如字符串前带 uint16 长度）必须手动组合逻辑，不能全丢给它。
- 先读长度字段：
binary.Read(r, order, &length) - 再分配切片：
data := make([]byte, length) - 再读内容：
io.ReadFull(r, data)（别用Read，它可能只读一部分） - 注意：如果流末尾不足，
io.ReadFull返回io.ErrUnexpectedEOF，不是 EOF
struct 字段对齐导致 binary.Write 写出多余填充字节
Go struct 在内存中按字段类型自然对齐（如 int64 对齐到 8 字节边界），但二进制协议通常要求紧密打包（no padding）。直接写 struct 会把 padding 也写进去，下游解析失败。
立即学习“go语言免费学习笔记（深入）”；
- 加
//go:notinheap没用，对齐由编译器决定，不可控 - 正确做法：用
unsafe.Offsetof+unsafe.Slice（Go 1.17+）逐字段提取原始字节，或手写MarshalBinary - 更稳妥：放弃 struct 直接操作，改用
[]byte+ 偏移量方式拼包（尤其在嵌入式/协议栈场景）
二进制序列化真正麻烦的从来不是函数怎么调，而是协议定义和内存布局之间那层看不见的 gap —— 字段顺序、对齐、符号位、空终止符，每个都可能让两个看似正常的 Read/Write 调用彻底失联。
