binary.write必须显式传字节序，漏传会panic；结构体字段须导出且为定长类型；变长字段需手动分步处理长度与内容；网络读取须先分包再解析。
binary.Write 必须显式传字节序，漏传直接 panic
Go 的 encoding/binary 不设默认字节序，binary.Write 第二个参数必须是 binary.LittleEndian 或 binary.BigEndian。漏传或传 nil 会触发 panic：binary.Write: invalid type interface {}——这不是类型错误，而是底层反射因缺失 binary.ByteOrder 实例失败。
常见误写：
-
binary.Write(w, data)❌ 缺少字节序参数 -
binary.Write(w, nil, data)❌nil不是合法的binary.ByteOrder
正确写法：
binary.Write(w, binary.LittleEndian, uint32(0x12345678))binary.Write(w, binary.BigEndian, int16(-100))
注意：w 必须实现 io.Writer（如 *os.File、*bytes.Buffer），且写入对象只能是定长类型或其切片/指针。
结构体编码前必须导出字段 + 定长类型
binary.Write 和 binary.Read 对结构体只按声明顺序逐字段处理，且仅读写**首字母大写的导出字段**。小写字段（如 id int32）会被静默跳过，值保持零值，极易导致协议解析错位。
同时，所有字段必须是定长基础类型：
- ✅ 允许：
uint32、int16、[32]byte、[8]uint64 - ❌ 禁止：
int（平台相关）、string、[]byte、map[string]int、interface{}
示例错误结构体：
type BadHeader struct {
magic uint32 // 小写 → 被跳过
len int // 平台相关 → panic
name string // 变长 → panic
}
应改为：
type GoodHeader struct {
Magic uint32
Len uint16
Name [32]byte
}
变长字段不能直传，必须分步：长度 + 内容
binary.Write 遇到 string 或 []byte 会 panic：invalid type string。它不支持变长内容的自动序列化。
正确做法是手动拆解：
- 先写长度（用定长整数，如
uint16或uint32） - 再写原始字节内容（
w.Write([]byte(s))）
例如写一个带长度前缀的 UTF-8 字符串：
str := "hello" binary.Write(w, binary.LittleEndian, uint16(len(str))) // 长度 w.Write([]byte(str)) // 内容
读取时严格反向：先 binary.Read(r, order, &n) 得长度，再用 io.ReadFull(r, buf[:n]) 读满内容。忽略长度校验可能引发越界或阻塞。
网络读取必须先分包，否则 binary.Read 会错位
直接把 net.Conn 当作 io.Reader 丢给 binary.Read，90% 场景会失败。TCP 是字节流，没有天然包边界；binary.Read 会从任意位置开始读，导致魔数错位、长度字段被截断、后续全乱。
标准流程只有三步：
- 先读固定长度包头（如
uint32表示包体长度） - 分配缓冲区并用
io.ReadFull(r, buf)读满整个包体（不是io.Read） - 用
bytes.NewReader(buf)或bytes.Buffer将完整包体交给binary.Read解析
务必校验包长度是否超出安全上限（如 > 1MB），防止内存耗尽。粘包不是 binary 的问题，是协议层必须解决的前置条件。
最易被忽略的点：binary 不做任何猜测和兼容——你写的字节序、字段顺序、类型位宽、包边界，必须和协议文档一字不差。差一个字节，就全错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
