binary.read读不出数据或数值错乱，主因是字节序错、字段未导出（须首字母大写）、结构体含变长类型（如string/[]byte）或tcp未分包；它不报错，只静默错读或panic。
binary.Read 读不出数据或数值错乱，基本就是字节序、字段导出、结构体对齐三者之一没对上——它不报错，只静默跳过或错读。
binary.Read 总是读出 0 或极大随机数？先抓包看 hex
根源几乎全是字节序（endianness）没对齐。Go 不检测、不提示、不自动适配，传错就错到底。
- 抓包看原始 hex：前 4 字节是
00 00 01 00→ 对应uint32= 256 → 协议用大端 → 必须传binary.BigEndian - 如果是
00 01 00 00→ 小端 → 必须用binary.LittleEndian - 别在同一个数据流里混用两种序，除非协议明确分段定义
- Python 的
struct.pack('iih')默认小端，Go 端必须用binary.LittleEndian
结构体字段首字母小写？binary.Read 直接跳过
字段名首字母小写（如 id int32）会被 binary.Read 完全忽略，不报错也不赋值，值保持零值。
- 所有参与编解码的字段必须首字母大写（如
ID int32），哪怕只是临时 struct -
binary.Read完全无视json:或binary:tag，只按字段声明顺序和原生大小读取 - 嵌套 struct 也必须满足导出 + 定长 + 字节序一致
- 用
unsafe.Sizeof检查 struct 实际大小，确认和协议文档中字节数一致
含 string 或 []byte 的 struct 一读就 panic？这是设计行为
binary.Read 明确拒绝变长类型：[]byte、string、map、interface{} 全部触发 panic: "invalid type"。
- 字符串字段不能写
Name string，得改成Name [32]byte，读完后用bytes.TrimRight(name[:], "\x00")去零再转string() - 真要支持 UTF-8 名字？协议里必须带长度前缀：先读
nameLen uint16，再用io.ReadFull(r, nameBuf[:nameLen])读满 - 别把整个 struct 丢给
binary.Write——尤其含 slice 字段时，手动分字段写更稳、更易调试 - 禁用
int/uint：它们在 32 位和 64 位平台长度不同，协议里写死的是int32或uint16，你就得用对应定长类型
直接 binary.Read 文件或 net.Conn？90% 失败源于未分包
TCP 是字节流，没有包边界；binary.Read 不会“猜”哪是开头。魔数错位、长度字段被截半、后续全乱。
- 协议头前 N 字节为总包长（推荐
uint32），先用binary.Read(r, order, &pkgLen)读出长度 - 立刻校验
pkgLen是否合理（如 ≤ 1MB），防内存耗尽攻击 - 分配
data := make([]byte, pkgLen)，再调用io.ReadFull(r, data)—— 注意是ReadFull，不是Read - 拿到完整包后，用
bytes.NewReader(data)交给binary.Read解析内部字段 - 别复用
conn本身做多次binary.Read，每次都要基于完整包切片构造新 reader
最容易被忽略的点是：binary.Read 不处理粘包、不检查字段对齐、不验证协议长度——它只搬运字节。你得自己确保字节流已切分成完整包，且结构体布局与协议二进制格式严丝合缝。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
