binary.Read 读不出加密头字段是因为加密头需严格按字节顺序定义导出、定长、对齐的结构体，且魔数应先用 io.ReadFull 读取字节切片校验，而非直接 binary.Read 解析。
binary.Read 读不出加密头字段？先确认它是不是真在“头”里
加密头不是指字段加了密，而是协议设计上把校验、密钥标识、算法类型等元信息放在固定位置的头部区域。如果 binary.Read 解出来全是零或乱值，大概率不是加密问题，而是你把它当普通结构体读了——但加密头往往含魔数（如 []byte{0x45, 0x4E, 0x43, 0x52}）、版本号、IV 长度等混合类型，甚至前 4 字节是魔数（uint32），后 2 字节是算法 ID（uint16），中间还夹着 16 字节随机 salt（[16]byte）。这种结构必须严格按字节顺序和类型定义 struct，且所有字段都得导出、定长、字节序对齐。
常见错误现象：
- 魔数字段读成
0：结构体字段名小写（如magic uint32→ 应为Magic uint32） - IV 偏移错位：用了
int而非int32，64 位系统占 8 字节，后续字段全偏 - salt 读成空：声明为
Salt []byte→ panic；必须写成Salt [16]byte
魔数校验失败就停，别往下读加密负载
加密头里的魔数（Magic Number）是协议可信起点。不能靠文件扩展名或路径判断，必须用 io.ReadFull 读固定长度字节切片后比对。用 binary.Read 去读魔数本身是反模式——它会把 0x454E4352 当作一个整数解析，而实际你只关心这 4 个字节是否精确匹配。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 分配
head := make([]byte, 16)，用io.ReadFull(r, head)一次读满 - 用
bytes.Equal(head[:4], []byte{0x45, 0x4E, 0x43, 0x52})校验，别转 string - 校验失败立刻返回错误，不继续解析后续字段，避免误用无效密钥解密
- 若头中含 CRC 或校验和字段（如
Crc32 uint32），在校验魔数后、读负载前，用crc32.ChecksumIEEE(head[:12])验证头完整性
加密负载长度字段必须单独读，且立即校验
加密后的负载（ciphertext）长度通常不固定，所以协议头里必然有一个长度字段（如 PayloadLen uint32），它本身是明文、定长、带字节序的。这个字段绝不能和结构体一起丢给 binary.Read 后直接用于 make([]byte, payloadLen) —— 攻击者可伪造极大数值触发 OOM。
正确流程：
- 先用
binary.Read(r, order, &payloadLen)单独读长度字段（确保该字段在 struct 中位置准确、类型为uint32或uint16） - 立刻检查：
if payloadLen == 0 || payloadLen > 10*1024*1024 { return errors.New("invalid payload length") } - 再分配
cipherBuf := make([]byte, payloadLen)，用io.ReadFull(r, cipherBuf)读满 - 别用
Read：TCP 流或损坏文件中少一字节，cipherBuf就缺尾部，解密必失败或 panic
解密后的内容怎么安全转回原始结构体
解密得到的是原始明文字节流，它可能仍是自定义二进制格式（比如含 header + body），但此时已无加密保护。不能直接把解密后的 []byte 传给 binary.Read —— 它需要 io.Reader，且要求数据完整、无粘包。
推荐做法：
- 用
bytes.NewReader(decrypted)包一层，再传给binary.Read - struct 定义必须和明文协议完全一致（字段顺序、大小、导出性），且不能含任何变长字段
- 若明文结构含字符串，仍需拆解：先读
NameLen uint16，再io.ReadFull读nameBuf[:nameLen]，最后string(bytes.TrimRight(nameBuf[:nameLen], "\x00")) - 注意：解密后若需校验完整性（如 HMAC），应在解密后、结构体解析前完成，否则攻击者可篡改明文结构字段
