binary.read读fixed-length string字段全为\x00，因字段未导出（小写名被静默跳过）或未裁剪填充零；必须首字母大写声明如name [32]byte，读完用bytes.trimright(h.name[:], "\x00")去零再转string。
binary.Read 读 fixed-length string 字段为啥全是 \x00？
不是数据没传过来，是 Go 把 [32]byte 当成原始字节块读进去了，但你直接 string(h.Name[:]) 拿到的是带尾部填充零的字符串——协议里“abc”写成 61 62 63 00 00 ...，转 string 就变成 "abc\x00\x00..."。更糟的是，如果字段声明成小写 name [32]byte，binary.Read 直接静默跳过，整个字段保持零值。
- 字段名必须首字母大写：
Name [32]byte，否则被忽略 - 读完必须显式裁剪：
bytes.TrimRight(h.Name[:], "\x00")，再转string() - 别用
string(h.Name[:])，它不自动去零，也不检查实际内容长度 - 若协议允许 UTF-8 变长内容，必须拆成两步：先读
NameLen uint16，再io.ReadFull(r, h.NameBuf[:h.NameLen])
如何用 io.ReadFull 安全拆出固定长度记录？
别用 conn.Read(buf)，它可能只读到部分字节就返回；也别自己循环拼接，末尾残缺时极易错位。真正可靠的是 io.ReadFull —— 它要么填满整个缓冲区，要么明确报错。
- 每条记录长度为
recordLen，分配复用缓冲区：buf := make([]byte, recordLen)（高并发下建议用sync.Pool复用） - 调用
io.ReadFull(conn, buf)，成功即表示拿到完整一条记录 - 错误只可能是：
io.EOF（文件/连接正常结束）、io.ErrUnexpectedEOF（剩余字节不够一条，记录损坏，应丢弃或告警） - 绝对不要靠
len(n)判断是否读满 ——io.ReadFull不会返回部分数据
为什么粘包一高并发就随机出错？
因为没做分包，直接把 net.Conn 丢给 binary.Read。TCP 是流，binary.Read 却当它是包——一次 Read 可能跨两个业务消息，也可能只读半个 header，后续所有字段全偏移。
- 必须加协议头：前 4 字节为
uint32包长（推荐binary.BigEndian） - 先
io.ReadFull(conn, header[:4])→binary.BigEndian.Uint32(header)得到pkgLen - 立刻校验：
if pkgLen == 0 || pkgLen > 1<code>MB，超限直接断连 - 再
data := make([]byte, pkgLen)+io.ReadFull(conn, data)拿到完整 payload - 最后用
bytes.NewReader(data)交给binary.Read解析内部结构
struct 字段对齐错位怎么快速定位？
字段值全零、数值巨大、字符串乱码——八成是内存布局和协议不一致。Go 编译器会按对齐规则插 padding，而二进制协议通常要求紧凑排列。
- 用
unsafe.Sizeof(Header{})检查 struct 实际大小，必须和协议文档标称字节数完全一致 - 禁用嵌套 struct，所有字段平铺（如把
Timestamp struct{ Sec, Nano uint32 }拆成TSec, TNano uint32） - 用
unsafe.Offsetof(h.Version)逐个核对每个字段起始 offset，和 hex 抓包位置比对 - 协议头含魔数？声明为
Magic [4]byte，别用string或小写magic [4]byte
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
