binary.Read/Write 编解码需确保字段全大写、定长、显式字节序，禁用变长类型，手动处理长度与粘包，校验大小与上限，复用缓冲区以提升稳定性与性能。
直接用 binary.Read 和 binary.Write 封装二进制协议编解码器，90% 的失败不是性能问题，而是字段导出、字节序错位、变长字段 panic 或 TCP 粘包导致的逻辑崩坏——高性能的前提是先跑通、再复用、最后压测。
struct 字段必须全大写且定长，否则 binary.Read 静默跳过
Go 的 binary.Read 不看 json: 或 binary: tag，只按字段声明顺序和原生大小读取。小写字母开头的字段（如 id int32）会被完全忽略，不报错、不赋值、结果全是零值。
- 所有参与编解码的字段名首字母必须大写，例如
ID int32、NameLen uint16 - 嵌套 struct 里的字段也得导出，不能只导出外层结构体
- 禁用
int/uint：它们长度随平台变化（32 位 vs 64 位），协议里写死的是int32就必须用int32 - 用
unsafe.Sizeof校验 struct 实际大小是否与协议文档一致，比如int在 64 位系统占 8 字节，但协议可能只要 4 字节
变长字段必须手动拆解：先读长度，再读内容
binary.Read 遇到 string、[]byte、map 会直接 panic："invalid type"。这不是 bug，是设计契约：它只处理定长原始类型。
- 协议中必须显式预留长度字段，如
NameLen uint16，且该字段自身字节序要和协议一致 - 先调
binary.Read(r, order, &nameLen)提取长度值 - 再分配缓冲区：
nameBuf := make([]byte, nameLen)，并严格用io.ReadFull(r, nameBuf)（不是Read）保证读满 - 若为字符串，用
bytes.TrimRight(nameBuf, "\x00")去 C 风格填充零，再转string() - 务必校验长度上限：
if nameLen > 1024 { return errors.New("name too long") }，防恶意构造
TCP 粘包必须在 binary.Read 前完成分包
把 net.Conn 直接传给 binary.Read，等于放弃稳定性。TCP 是字节流，binary.Read 不知道包头在哪、包尾在哪，一次读可能跨两个包，也可能只读半个 header。
立即学习“go语言免费学习笔记（深入）”；
- 协议头前 4 字节固定为总包长（推荐
uint32），先用binary.Read(conn, order, &pkgLen)提取长度 - 校验
pkgLen合理性（如 ≤ 1MB），防内存耗尽攻击 - 分配
data := make([]byte, pkgLen)，再调io.ReadFull(conn, data)拿到完整包体 - 最后用
bytes.NewReader(data)封装，交给binary.Read解析内部字段
性能关键点：别迷信 struct 一次性读写，优先复用缓冲区
binary.Read 最大开销往往不是解析本身，而是内存分配和 io 复制。高频场景下，反复 new bytes.Reader、频繁分配 []byte 会显著抬高 GC 压力。
- 放弃通用性：手写
MarshalBinary/UnmarshalBinary方法，字段顺序和偏移完全由代码控制 - 预分配缓冲区：
buf := make([]byte, 0, 64)，用binary.BigEndian.AppendUint16(buf, x)追加，避免小对象分配 - 固定长度字符串统一用
[32]byte，避免动态 length 字段带来的分支预测失败 - 别把整个 struct 丢给
binary.Write，尤其含 slice 字段时——手动逐字段写更稳，也更容易插校验和日志
最易被忽略的一点：你写的不是“解析器”，而是对 wire bytes 的精确映射。协议文档里的每个字节偏移、每个字段大小、每个字节序，都必须在代码里有且仅有一处对应。多一个字段、少一个 padding、错一个大小端，整包就废。这不是调试问题，是契约对齐问题。
