binary.Read 读不出正确值是因为字节序、字段导出性、类型长度三者未与协议对齐：字节序错导致数值解析错误；小写字段被静默跳过；int 等非定长类型引发错位；string/[]byte 等变长类型需拆解为长度+内容；TCP 粘包需先读包长再完整读取；net/rpc 的 ServerCodec 必须严格处理帧边界与 Header/Body 分离。
binary.Read 为什么总读不出正确值
不是代码写错了，而是字节序、字段导出、类型长度三者没对齐协议。抓包看到前 4 字节是 00 00 01 00，对应 uint32 值应为 256，但你传了 binary.LittleEndian，结果读成 0x00010000（65536）；结构体里写了 name string，首字母小写 → binary.Read 静默跳过，不报错也不赋值；字段声明用 int 而非 int32，64 位系统占 8 字节，协议只留 4 字节 → 后续所有字段全错位。
- 用
hexdump -C或 Wireshark 确认协议实际字节序，别猜 - 所有参与编解码的字段必须首字母大写（如
ID uint32、NameLen uint16） - 禁用
int/uint，改用int32、uint16等定长类型 - 字段顺序必须和协议文档一字不差，调换任意两个字段都会导致偏移错乱
含字符串或切片的 struct 怎么安全读写
binary.Read 遇到 string、[]byte、map 会直接 panic: invalid type——这不是 bug，是设计契约：它只处理定长原始数据。协议里“用户名”不能是裸字段，必须拆成“长度字段 + 内容块”两部分。
- 固定长度字符串用
[32]byte，读完后bytes.TrimRight(name[:], "\x00")去零再转string() - 真正变长内容（如 UTF-8 名称）必须带长度前缀：先
binary.Read(r, order, &nameLen)（类型必须是uint16或uint32），再io.ReadFull(r, nameBuf[:nameLen]) - 务必校验
nameLen是否越界：if nameLen > 1024 { return errors.New("name too long") } - 别把整个 struct 丢给
binary.Write，尤其含 slice 字段时，手动逐字段写更可控
TCP 粘包导致 binary.Read 解析失败怎么办
把 net.Conn 直接当 io.Reader 传给 binary.Read，等于让解析器在流动字节流里盲猜包边界。一次 Read() 可能只拿到半个 header，下一次又读到拼在一起的两条完整消息，魔数错位、长度字段被截断，后续全乱。
- 协议头前 4 字节必须是固定长度字段（如
uint32大端），先用binary.Read(r, order, &pkgLen)提取 - 分配
data := make([]byte, pkgLen)，严格用io.ReadFull(r, data)（不是Read）确保读满 - 拿到完整包后，用
bytes.NewReader(data)包一层，再交给binary.Read解析内部字段 - 必须校验
pkgLen是否过大：if pkgLen > 1024*1024就拒绝，防内存暴涨
net/rpc 的 ServerCodec 接口不能只换序列化格式
ServerCodec 不是“换 JSON 为 Protobuf”那么简单，它强制你接管整个帧读写逻辑：Header/Body 分离、消息边界、错误传播、TCP 粘包处理，漏掉任一环都会导致连接静默断开或响应错乱。常见错误是在 WriteRequest 中直接 json.Marshal(req) 一整坨发出去 → 缺少 Header 分界，服务端 ReadRequestHeader 读不到方法名，直接丢弃连接。
立即学习“go语言免费学习笔记（深入）”；
- Header 和 Body 必须分离序列化：
method、seq、error是 net/rpc 内部约定字段名，不能改 -
ReadRequestHeader必须先读长度头 →io.ReadFull(conn, lengthBuf[:])→ 再按长度读完整帧 → 最后从帧中解析 Header - 切忌用
bufio.Scanner或bytes.Split处理二进制帧——它们面向文本，遇到\x00就截断 - Header 解析失败必须返回 error，不能吞掉，否则客户端收不到响应且连接可能卡死
