Go二进制传输无万能框架，需按场景选型：gob仅适用于可信内网长连接；跨语言或对外API须用MessagePack/Protobuf；binary.Read失败主因是字节序、字段导出、类型大小及分包处理不当。
Go 语言里处理二进制数据传输，没有“万能框架”，只有“场景匹配方案”。高频小数据、可信内网、纯 Go 生态——encoding/gob + 长连接 TCP 是当前最轻、最快、最稳的选择；一旦涉及跨语言、不可信输入或协议需长期演进，就必须放弃 gob，转向 MessagePack 或 Protocol Buffers。
为什么 encoding/gob 不该用在对外 API 或微服务网关
gob 是 Go 的“方言”，不是通用协议。它不提供跨语言解析能力，也不做类型白名单校验——恶意构造的 gob 数据可能触发未注册类型的反序列化 panic，甚至绕过 Decoder.Register 造成内存越界（尤其在老版本 Go 中）。更关键的是：字段增删后，旧客户端 decode 会直接失败，无兼容层可退。所以它只适合：net/rpc 内部调用、服务间长连接状态同步、本地快照存盘这类强信任、短生命周期、无外部依赖的场景。
encoding/binary 读不出数据？先查字节序和字段导出状态
90% 的 binary.Read 失败不是逻辑错，而是底层约定没对齐：
- 抓包看到前 4 字节是
00 00 01 00，对应值应为 256 → 协议是大端 → 必须传binary.BigEndian，传LittleEndian会读成 65536 - 结构体字段名首字母小写（如
id int32）→binary.Read静默跳过，不报错也不赋值 - 用
int替代int32→ 在 32 位机器上是 4 字节，64 位上是 8 字节，协议字节数直接错位 - 字段顺序和协议文档不一致 → 后续所有字段全部偏移，debug 时很难定位
变长字段必须手动拆解：长度前缀 + 分步读写
binary.Read 和 binary.Write 明确拒绝 string、[]byte、map —— 这不是 bug，是设计契约。想传用户名、JSON payload 或加密密文，不能塞进 struct 直接读写：
立即学习“go语言免费学习笔记（深入）”；
- 协议头中预留一个
uint16或uint32字段表示后续内容长度 - 先用
binary.Read(r, order, &length)提取长度值 - 校验
length合理性（如if length > 1024 { return errors.New("name too long") }） - 再用
io.ReadFull(r, buf[:length])读满（不能用Read，否则可能只读一半） - 若内容是 C 风格字符串，记得
bytes.TrimRight(buf[:length], "\x00")去零再转string()
TCP 粘包必须在应用层封包，不能靠 binary.Read 自动识别
把 net.Conn 直接丢给 binary.Read，等于放弃稳定性。TCP 是字节流，binary.Read 不知道哪是包头、哪是包尾。一次 Read 可能跨两个包，也可能只读半个 header：
- 发送端：协议头前 4 字节写入总包长（
binary.BigEndian.PutUint32(header[:], uint32(len(payload)))），拼接完整数据后写入连接 - 接收端：必须先读 4 字节提取
pkgLen，校验范围（如 ≤ 1MB），再分配 buffer 并io.ReadFull读满，最后才交给binary.Read解析内部字段 - 别省这一步——哪怕只是原型验证，粘包问题在压测时一定会暴露，且极难复现
真正难的从来不是“怎么写”，而是“怎么让每次读都拿到完整、正确、可控的一包”。字节序、导出规则、长度校验、分包边界——这些点漏掉任何一个，都会让二进制协议从性能优势变成线上事故源头。
