魔数必须是uint32且大端序，以确保跨平台和C/C++通信时无歧义解析；协议头固定为4字节魔数+2或4字节长度字段，需立即校验长度防OOM，并用encoding/binary显式处理字节序。
魔数为什么必须是 uint32 且大端序
魔数不是随便选的 4 字节字符串，它得能被网络字节序（大端）无歧义解析，否则跨平台或与 c/c++ 服务通信时会直接错读。比如你写 "magi"，在内存里按字节存是 0x4d 0x41 0x47 0x49，但若用 binary.read(buf, binary.littleendian, &magic)，就会变成 0x4947414d，对方永远对不上。
实操建议：
- 魔数统一用
uint32字面量定义，例如const MagicNumber uint32 = 0x4D414749（对应 "MAGI"） - 序列化/反序列化全程使用
binary.BigEndian，包括魔数和后续长度字段 - 避免用字符串转字节再拼接——
[]byte("MAGI")看似直观，但后续和uint32混合读写时极易字节序错位
长度字段放哪儿、占多少字节、怎么校验
长度字段必须紧挨魔数之后，且必须是固定长度（常见为 uint32 或 uint16），不能可变。否则解析器无法知道从哪开始读 payload，也就没法做基础粘包处理。
实操建议：
- 协议头固定为 6 字节：4 字节
MagicNumber+ 2 字节uint16长度（适合单包 ≤ 64KB 场景）；或 8 字节：4+4（支持 ≥ 4GB payload，但极少需要） - 读取长度后，立即检查是否超出预设上限（如
if length > 1024*1024 { return ErrPacketTooLarge }），防止恶意构造超长包导致 OOM - 不要等整包收完再校验魔数——先读 4 字节，比对
MagicNumber，不匹配就丢弃并重同步，避免错误累积
Go 中用 encoding/binary 构造和解析的典型写法
别手撸 bytes.Buffer.Write() 拼包，容易漏字节序或错偏移；也别用 unsafe 强转，破坏内存安全且不可移植。
立即学习“go语言免费学习笔记（深入）”；
正确做法是用 encoding/binary 显式控制：
// 打包
func MarshalPacket(payload []byte) ([]byte, error) {
if len(payload) > math.MaxUint16 {
return nil, errors.New("payload too long")
}
buf := make([]byte, 6+len(payload))
binary.BigEndian.PutUint32(buf[0:], MagicNumber)
binary.BigEndian.PutUint16(buf[4:], uint16(len(payload)))
copy(buf[6:], payload)
return buf, nil
}
// 解包（需保证至少读到 6 字节才开始解析）
func ParsePacket(buf []byte) ([]byte, error) {
if len(buf) < 6 {
return nil, io.ErrUnexpectedEOF
}
magic := binary.BigEndian.Uint32(buf[0:])
if magic != MagicNumber {
return nil, errors.New("invalid magic number")
}
length := int(binary.BigEndian.Uint16(buf[4:]))
if length < 0 || length > 1024*1024 {
return nil, errors.New("invalid packet length")
}
if len(buf) < 6+length {
return nil, io.ErrUnexpectedEOF
}
return buf[6 : 6+length], nil
}
为什么不能把魔数和长度都塞进 struct 里用 binary.Read/Write
看起来很干净：type Header struct { Magic uint32; Length uint16 }，但实际踩坑率极高——struct 默认内存布局受字段对齐影响，uint32 后跟 uint16 可能被编译器自动填充 2 字节，导致写出来是 8 字节而非预期 6 字节。
更隐蔽的问题是：如果 header struct 后面紧跟 payload，binary.Write(w, order, &header) 写完 header 就停了，你得手动再写 payload，中间一旦出错（比如忘记 written += 6），长度字段就彻底失真。
所以真实项目中几乎没人这么干。坚持「头部分离构造」+「payload 独立拷贝」，虽然多几行代码，但边界清晰、调试友好、无隐式填充风险。
真正容易被忽略的是：TCP 是字节流，没有消息边界。哪怕协议设计再严谨，ParsePacket 必须能处理半包（只读到前 5 字节）、粘包（一次收到两个完整包）、甚至跨包魔数（如上一个包末尾 3 字节 + 下一个包开头 1 字节凑成魔数）。这些逻辑不在协议定义里，但在 Conn.Read() 的实际使用中绕不开。
