binary.read不能直接解析带字符串或变长字段的配置文件，必须拆解为“定长头+变长内容”两步处理：先读定长头（字段全导出、定长类型、字节序对齐），再按长度前缀手动读变长内容并校验；struct必须严格按协议字节布局定义，否则值为零或乱码。
binary.Read 不能直接解析带字符串或变长字段的配置文件——它会 panic 或静默跳过未导出字段，读出来的值基本是零或乱码。必须拆解为“定长头 + 变长内容”两步处理，且每步都需校验。
struct 定义必须严格对齐协议字节布局
Go 的 binary.Read 不看 struct tag，只按字段声明顺序、类型大小、字节序逐字节搬运。协议里第一个字段是 uint32 版本号，你就得把 Version uint32 放 struct 第一个位置；中间插了个 [32]byte 名字字段，就得写成 Name [32]byte，不能用 string 或 []byte。
常见错误现象：Version 总是 0，Name 是空字符串——大概率是字段没导出（小写开头）、顺序错位、或用了 int 而非 int32。
- 所有字段名首字母必须大写（导出）
- 禁用
int/uint，改用int32、uint16等定长类型 - 字符串字段必须转成固定长度数组，例如
Name [64]byte - 如果协议文档写的是“Name 后跟 \x00 填充至 64 字节”，那就真得填满，否则
binary.Read仍会读满 64 字节
变长字段必须手动分步读取
配置文件里如果有路径、描述这类长度不固定的字段，绝不能塞进 struct 交给 binary.Read。它不支持 string，一读就 panic: invalid type。
正确做法是：先读长度字段（如 DescLen uint16），再分配缓冲区，再用 io.ReadFull 读满。
- 长度字段本身也必须指定字节序，比如
binary.Read(r, order, &descLen) - 立刻校验
if descLen > 4096 { return errors.New("description too long") } - 复用预分配缓冲区：
descBuf := make([]byte, descLen)，避免每次make触发 GC - 用
io.ReadFull(r, descBuf)，不是r.Read(descBuf)—— 后者可能只读一部分，导致后续字段全偏移 - 转字符串前清理填充：
string(bytes.TrimRight(descBuf, "\x00"))
文件头校验和字节序必须靠抓包确认
别猜字节序。打开 hex 编辑器看前几个字节，或用 xxd 查原始数据：
xxd -l 16 config.bin 输出 00000000: 0100 0000 0a00 0000 6874 7470 0000 0000 ........http.... → 前 4 字节是 01 00 00 00，对应值 1，说明是小端 → 必须传 binary.LittleEndian。
如果输出是 00000000: 0000 0001 0000 000a 6874 7470 0000 0000 ........http.... → 前 4 字节 00 00 00 01，值 1，是大端 → 用 binary.BigEndian。
- 字节序错配会导致数值异常：本该是 256，读出来是 4294967296
- 配置文件通常带魔数（magic number），读完头字段后应校验，例如
if header.Magic != 0x46434701 { return errors.New("invalid magic") } - 不要在同一个 reader 上混用不同字节序，除非协议明确分段定义
读完整文件后别直接丢给 binary.Read
配置文件通常是单个完整 blob，但 binary.Read 默认从当前 offset 开始读。如果文件开头有魔数或长度字段，你得先跳过或单独读，再把剩余部分交给 binary.Read。
更稳妥的做法是：用 os.ReadFile 一次性加载，然后用 bytes.NewReader(data[headerSize:]) 构造新 reader，避免 file.Seek 出错或状态残留。
- 如果文件很大（>10MB），改用
io.ReadFull分块读，但必须自己维护 offset 和剩余长度 - 读完记得检查是否 EOF：若
binary.Read返回io.EOF，说明数据不足，不是正常结束 - 别复用同一个
*bytes.Reader多次调用binary.Read，容易因内部 offset 错乱导致后续读错
descLen 可能是攻击者伪造的，不校验就 make([]byte, descLen)，轻则 OOM，重则被利用。而反复 make 小缓冲区，在高频解析场景下会显著拖慢性能。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
