Go的binary包需按字段顺序手动读写固定大小类型结构体，禁用指针/切片/map；须用io.ReadFull确保定长读取；变长字段需先读长度再读内容；避免unsafe和reflect，推荐gob或protobuf；务必校验magic/CRC。
用 binary.Read 和 binary.Write 读写结构体二进制数据
Go 标准库的 encoding/binary 包不支持自动序列化任意结构体，但能按字段顺序、指定字节序（binary.LittleEndian 或 binary.BigEndian）逐字段读写。前提是结构体字段必须是固定大小类型（如 int32、uint64、[8]byte），且不能含指针、切片或 map。
常见错误：直接对含 []byte 字段的结构体调用 binary.Read，会 panic —— 因为切片头不是二进制可映射的原始数据。
- 先用
binary.Write写入定长字段，例如：type Header struct { Magic uint32 Length uint16 Flags uint8 } buf := new(bytes.Buffer) binary.Write(buf, binary.LittleEndian, Header{Magic: 0x464c457f, Length: 1024, Flags: 1}) - 读取时确保缓冲区长度足够，否则
binary.Read返回io.ErrUnexpectedEOF - 字节序必须读写一致；网络协议常用
BigEndian，本地文件处理常选LittleEndian
用 bytes.Buffer + io.ReadFull 安全读取定长二进制块
从网络连接或文件读取固定长度二进制数据（如协议头、加密块）时，不能依赖 io.Read 一次返回全部字节——它可能只读部分。必须用 io.ReadFull 强制读满，否则后续解析会错位。
-
io.ReadFull成功时返回nil；若底层 reader 提前 EOF，返回io.ErrUnexpectedEOF；若根本读不到任何字节，返回io.EOF - 配合
bytes.Buffer或make([]byte, n)预分配切片，避免反复扩容 - 示例：
header := make([]byte, 8) _, err := io.ReadFull(conn, header) if err != nil { // 处理不完整读取 } // 解析 header[0:4] 为 uint32，header[4:8] 为 uint32
处理变长二进制字段：先读长度，再读内容
真实协议中常有“长度前缀 + 数据”格式（如字符串、TLV）。Go 没有内置函数自动处理，需手动组合 binary.Read 和 io.ReadFull。
立即学习“go语言免费学习笔记（深入）”；
- 长度字段本身必须是定长（如
uint16表示最多 64KB 数据），否则无法启动解析 - 读出长度后，立即检查是否过大（防内存爆炸），再分配切片并用
io.ReadFull读取 - 注意字节序一致性：长度字段和后续数据字段若属于同一协议，应使用相同 endian
- 示例：
var length uint16 err := binary.Read(r, binary.BigEndian, &length) if err != nil { return err } if length > 1024*1024 { return errors.New("payload too large") } payload := make([]byte, length) _, err = io.ReadFull(r, payload) // r 是 *bytes.Reader 或 net.Conn
避免 unsafe 和 reflect 序列化结构体的陷阱
有人尝试用 unsafe.Pointer 把结构体转 []byte 来绕过 binary 限制，这在含 padding、非导出字段或 GC 堆上对象时极易崩溃或读到脏数据。反射方案（reflect.StructField.Offset + 手动拼接）虽可行，但性能差、难维护、不兼容 go vet。
- 真正需要灵活二进制格式时，应改用
gob（Go 内置，但仅限 Go 间通信）或protobuf（跨语言、带 schema） - 若坚持手写二进制协议，把结构体拆成多个
binary.Read调用，显式控制每个字段的读写逻辑，比黑盒转换更可靠 - 所有二进制操作必须伴随校验：CRC32、Adler32 或简单 magic number，否则损坏数据会静默导致解析偏移
