binary.read 字段全零或错位的根源是结构体内存对齐与字段导出问题：字段须全大写、用定长类型（如 uint32、[4]byte）、禁用 string 和平台相关类型；禁止嵌套 struct，平铺字段并严格校验 offset、字节序、长度及填充。
binary.read 读出字段全为零或错位？问题几乎一定出在结构体内存对齐和字段导出上，不是代码写错了，是 go 编译器悄悄加了填充字节，而协议没留这个空。
struct 字段必须全部大写且用定长类型
小写字段（如 id int32 或 name string）会被 binary.Read 静默跳过，不报错也不赋值；string 还会直接 panic。必须全部首字母大写，并禁用 int/uint 这类平台相关类型。
-
ID uint32、Version [4]byte、NameLen uint16—— 全部大写 + 定长 - 字符串字段不能用
string，改用[32]byte；读完后用bytes.TrimRight(h.Name[:], "\x00")去零再转string() - 用
unsafe.Sizeof(Header{})核对实际字节数，必须和协议文档标称长度完全一致
禁止嵌套 struct，平铺字段防编译器填充
Go 编译器会对字段自动填充以满足对齐要求。比如 uint32 + uint8 后可能插入 3 字节 padding，导致后续字段整体偏移。协议若要求紧凑布局（无填充），就不能靠嵌套或默认内存布局。
- 把子结构（如
Timestamp）拆成TSec uint32、TNano uint32等平级字段 - 若协议头含魔数、版本、类型、长度四字段，就声明为四个独立大写字段，顺序一字不差
- 别信 “看起来一样就行”，
unsafe.Offsetof(h.Version)要和协议 offset 表严格对齐
裁剪靠手动控制，不是靠 struct 大小
你声明 Name [256]byte，但只填了前 10 字节，binary.Write 仍会写出全部 256 字节——后面全是 \x00。这不是 bug，是按类型大小硬写的。裁剪必须由你显式控制。
- 写字符串时：先
binary.Write(w, order, &h.NameLen)，再w.Write(h.NameBuf[:h.NameLen]) - 读字符串时：先
binary.Read(r, order, &h.NameLen)，再io.ReadFull(r, h.NameBuf[:h.NameLen]) - 长度字段本身也要校验：
if h.NameLen > 256 { return errors.New("name length overflow") }
包头长度字段的字节序必须单独确认
包头最前面那个 uint32 包长字段，它的字节序和后续字段可能不同。抓包看到 00 00 00 01 是大端（值为 1），01 00 00 00 才是小端（值也为 1）。用错会读出 16777216，直接 OOM。
- 先用
binary.Read(r, order, &pkgLen)单独读长度字段，order必须和协议文档一致 - 立刻校验：
if pkgLen == 0 || pkgLen > 1024*1024，超限直接返回错误 - 分配缓冲区后必须用
io.ReadFull(r, data)，不是io.Read，否则可能只读一半
真正难的不是写代码，是拿着 hex 抓包结果一行行比对每个字段的 offset、字节序、是否被填充、是否去零——这些地方一错，binary.Read 就静默失效，连 error 都不给你。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
