Go无法通过“语言学习”实现自定义编解码器，因其无运行时类型推断或动态schema解析能力，所有编解码逻辑必须显式定义、手动控制字节布局。
不能靠“语言学习”实现自定义编解码器——Go 没有运行时类型推断或动态 schema 解析能力，所有编解码逻辑必须由你显式定义、手动控制字节布局。所谓“学习”，其实是你对协议规范的理解和落地，不是语言自动完成的。
binary.Read / binary.Write 为什么总读错或 panic
它不“学”协议，只机械搬运字节：字段未导出、字节序反了、用了 int 而非 int32、结构体字段顺序和协议不一致，都会导致错位或 panic。
-
binary.Read完全忽略 struct tag（比如json:"name"或自定义binary:"size=4"），只按字段声明顺序 + 原生大小读 - 小写字母开头的字段（如
name string）会被静默跳过，不报错也不赋值 - 协议头是
00 00 01 00→ 对应uint32 = 256→ 必须用binary.BigEndian；若是00 01 00 00→ 就得换binary.LittleEndian - 字段类型必须定长：
int在 64 位系统占 8 字节，但协议只留 4 字节 → 后续全部错位
含字符串或 []byte 的结构体怎么安全编解码
binary 包不支持变长字段，string 和 []byte 直接塞进 struct 传给 binary.Read 必 panic。
- 固定长度字符串用
[32]byte，读完后用bytes.TrimRight(name[:], "\x00")去零再转string() - 真正变长内容（如 UTF-8 用户名）必须拆成两步：先读长度字段（如
nameLen uint16），再用io.ReadFull(r, buf[:nameLen])读内容 - 务必校验长度上限：
if nameLen > 1024 { return errors.New("name too long") } - 别把整个 struct 丢给
binary.Write—— 尤其含 slice 字段时，手动分字段写更可控
TCP 粘包下如何让 binary.Read 正确工作
直接把 net.Conn 当 io.Reader 传给 binary.Read，等于让它在流动字节流里盲猜边界，90% 会失败。
立即学习“go语言免费学习笔记（深入）”；
- 先读固定长度头（如 4 字节
uint32），用io.ReadFull(conn, header[:])确保读满 - 用
binary.BigEndian.Uint32(header[:])提取 payload 长度，显式转成uint32再和len(buf)比较（避免 32 位系统溢出） - 校验长度上限（如
> 1024*1024），超限直接丢弃整帧并清空缓冲区 - 分配
payload := make([]byte, frameLen)，再用io.ReadFull(conn, payload)读满整帧 - 最后用
bytes.NewReader(payload)包一层，才交给binary.Read解析内部字段
为什么不能依赖 encoding/json 或 gob 实现紧凑二进制协议
json.Marshal 输出文本、带引号、字段名不压缩、零值不跳过；gob.Encoder 不跨语言、不兼容遗留协议、无版本控制能力——二者都不满足紧凑、可控、可演进的二进制需求。
- 字段名压缩、零值跳过、自定义时间格式，只能靠手写
MarshalBinary/UnmarshalBinary - 协议含 magic number 或版本头，必须硬编码在
MarshalBinary开头，否则下游无法识别帧边界 - 版本变更必须用
switch version分支处理，老版本逻辑不能删，新代码要能降级解析旧数据 - 字段顺序必须固定，长度字段（如
nameLen uint8）必须在内容前，且拷贝前要检查缓冲区是否足够：if int(nameLen) > len(data)-3 { ... }
真正难的不是写几个函数，而是把协议文档里的每个字节位置、每个字段含义、每个边界条件都映射到代码里——漏掉一个校验，线上就可能 panic 或静默错解。
