encoding/binary 是解析固定结构二进制协议的首选，需先分包再按字节序读取，禁用 unsafe，TLV 等变长结构须手动解析，务必校验边界与超时。
用 encoding/binary 解析固定结构的二进制协议包
Go 标准库的 encoding/binary 是解析 TCP/UDP 二进制协议最常用、最稳妥的方式，适用于头部长度固定、字段顺序明确的协议（比如自定义心跳包、设备上报帧）。它不依赖反射，性能好，且能精确控制字节序。
常见错误是直接用 binary.Read 读整个连接流，结果因粘包导致解码失败。正确做法是先按协议约定提取完整包长（比如前 4 字节为 uint32 包体长度），再切片读取对应字节数。
- 必须显式指定字节序：
binary.BigEndian或binary.LittleEndian，和协议文档严格对齐 - 结构体字段不能有非导出字段（首字母小写），否则
binary.Read会跳过 - 字符串字段需转为定长
[N]byte或手动处理 null-terminated 字节数组
type Header struct {
Magic uint16
Length uint32
Cmd uint8
}
var hdr Header
err := binary.Read(r, binary.BigEndian, &hdr) // r 是 io.Reader，如 conn
if err != nil {
return err
}
// 接着读取 hdr.Length 字节的 payload
处理变长字段和 TLV 结构时用 bytes.Buffer + 手动偏移
当协议含 TLV（Tag-Length-Value）或嵌套变长字段（如 UTF-8 字符串、动态数组）时，binary.Read 不再适用。此时应把原始字节读入 []byte，用 bytes.Buffer 或直接下标操作逐步解析。
容易踩的坑是忽略边界检查：未验证剩余字节数就尝试读取，导致 panic 或静默错位。所有 readXxx 操作前都应校验 len(data) >= offset + size。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
buf.Next(n)安全截取 n 字节，返回[]byte；若不足则返回实际可用部分 - 字符串解码建议用
bytes.TrimRight(data, "\x00")去除 C 风格末尾零，再转string() - TLV 中的
Length字段本身也可能是变长编码（如 1~4 字节），需按协议规则先解析长度字段再读值
data := make([]byte, 1024) n, _ := conn.Read(data) buf := bytes.NewBuffer(data[:n]) tag := buf.Next(1)[0] length := binary.BigEndian.Uint16(buf.Next(2)) value := buf.Next(int(length)) // 注意这里要转 int
避免用 unsafe 或 reflect 直接内存映射结构体
有人尝试用 unsafe.Pointer 把字节切片强制转成结构体指针，看似简洁，但极不可靠：结构体字段对齐、填充、大小可能因编译器或 GOARCH 变化；且 Go 1.21+ 对 unsafe 使用限制更严，运行时可能 panic。
反射方式（如 binary.Read 底层虽用反射，但封装安全）若用于非导出字段或嵌套 slice，行为不可控，调试困难。
- 标准库
encoding/binary已足够高效，无需“优化”到 unsafe 层级 - 如果协议字段太多，可写代码生成器（如
go:generate+text/template）自动生成解析函数，而非硬编码 unsafe - 单元测试中务必覆盖字段对齐场景：在不同平台（amd64/arm64）交叉验证结构体大小是否一致
遇到粘包/半包必须自己实现分包逻辑
Go 的 net.Conn 是字节流，没有“消息边界”概念。TCP 协议层不保证一次 Read 返回一个完整应用层包。所有二进制协议解析前，必须解决分包问题。
最简方案是「包头定长 + 包体长度字段」，但要注意：长度字段自身是否包含包头长度？是否含校验和？这些细节协议文档常写得模糊，实测时最容易出错。
- 不要依赖
bufio.Reader的ReadSlice或ReadBytes，它们面向文本，对二进制无意义 - 推荐封装一个
PacketReader类型，内部维护缓冲区，暴露ReadPacket() ([]byte, error)方法 - 生产环境必须加超时和最大包长限制，防止恶意客户端发送超长 length 导致 OOM
func (r *PacketReader) ReadPacket() ([]byte, error) {
if len(r.buf) < 4 {
r.fill(4) // 至少读够包头
}
pktLen := binary.BigEndian.Uint32(r.buf[:4])
if pktLen > 10*1024*1024 { // 10MB 上限
return nil, errors.New("packet too large")
}
if uint32(len(r.buf)) < 4+pktLen {
r.fill(4 + pktLen) // 补齐整包
}
pkt := append([]byte(nil), r.buf[4:4+pktLen]...)
r.buf = r.buf[4+pktLen:]
return pkt, nil
}
协议解析真正难的不是读字节，而是和硬件/服务端文档对齐每一个 bit —— 魔数位置、校验算法、时间戳单位、枚举值含义，这些往往没写在 Go 代码里，却决定解析是否成功。 
