必须分步处理定长头+变长内容，否则binary.read会panic或错读；结构体需全导出、用固定大小类型、显式字节序、无slice/string字段，变长部分须单独读取并校验。
直接用 encoding/binary 解析二进制文件里的结构体，必须分步处理定长头 + 变长内容，否则会 panic 或静默错读——它不校验字段有效性，只按内存布局硬塞。
binary.Read 为什么读 struct 会 panic 或值错乱
常见错误现象：panic: invalid type（含 []byte、string 字段）、io.ErrUnexpectedEOF（读不满）、数值明显异常（如时间戳变负数）。
- 结构体含非导出字段（首字母小写），
binary.Read直接跳过，不报错也不赋值 - 用了
int这类平台相关类型，32 位系统和 64 位系统解出来长度不一致 - 字段含
[]byte或string，binary.Read立即 panic：“invalid type” - 没指定字节序（
binary.BigEndian/binary.LittleEndian），而协议实际是小端，结果01 00 00 00被当成 1 而不是 16777216 - 结构体字段之间有 padding（比如
uint8后跟uint32），编译器自动补 3 字节，但协议没留空，导致后续字段全部偏移
如何安全解析带变长字段的结构体（如用户名、payload）
Go 结构体不支持运行时决定数组长度（如 [len]byte），所以不能把变长部分写进 struct 定义里。必须拆成两步读取。
- 先定义纯定长头部，例如：
type Header struct { Len uint16 Type uint8 } - 用
binary.Read(r, order, &hdr)读出长度字段hdr.Len - 校验
hdr.Len合理（如 ≤ 1MB），防内存耗尽攻击 - 分配
data := make([]byte, hdr.Len)，再调io.ReadFull(r, data)保证读满 - 若需转为字符串，用
bytes.TrimRight(data, "\x00")去末尾零，再转string()
TCP 流中解析二进制协议必须先分包
net.Conn 是字节流，不是消息流。binary.Read(conn, ...) 一次调用可能只读半个 header，也可能跨两个完整包，后续全错。
- 协议头前 N 字节必须是总包长（推荐
uint32），且显式约定大小端 - 先用
binary.Read(conn, order, &pkgLen)读出长度（确保 conn 至少有 4 字节可用） - 用
io.ReadFull(conn, buf[:pkgLen])读取完整 payload，buf长度必须 ≥pkgLen - 把
buf[:pkgLen]封装成bytes.NewReader，再传给binary.Read解析内部结构 - 务必设读超时（
conn.SetReadDeadline），否则粘包卡住会永久阻塞
嵌套结构或 TLV 类型必须手动控制读取边界
binary.Read 不支持嵌套 struct、TLV、interface 或 map。它只认扁平、定宽、无指针的字段序列。
- 先读固定头拿到 tag 和 length 字段（如
binary.Read(r, order, &tag)→binary.Read(r, order, &length)） - 提前检查 reader 剩余长度是否 ≥
length（if r.Len() ） - 再用
io.ReadFull(r, valueBuf[:length])提取值 - 对每个子块，仍可用
binary.Read(bytes.NewReader(valueBuf), order, &subStruct)，但绝不能把整个嵌套 struct 丢进去 - 别用
unsafe.Slice强转字节切片为 struct 指针——字段对齐、padding、GC 逃逸在不同 GOARCH 下不一致，Go 1.21+ 会直接 panic
最容易被忽略的是：协议文档里写的“字符串字段”，几乎从来不是真正的 string 类型，而是“长度前缀 + 字节序列”。你得自己读长度、校验、截取、去零——binary.Read 不干这事，也不会提醒你漏了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
