binary.write 写 string 会 panic，必须先写长度再写 []byte；读取需严格按序还原，字节序不匹配会导致数值颠倒；struct 须导出、定长、无 padding；tcp 场景需处理粘包并用 io.readfull 确保完整读取。
binary.Write 写 string 会 panic，必须手动拆长度 + []byte
直接写 string 类型会立即 panic：`panic: binary.Write: invalid type string`。这不是类型转换失败，而是 binary.Write 明确拒绝所有变长类型——string 没有固定字节长度，无法摊平进二进制流。
正确做法是分两步：
- 先写长度字段（如
uint16或uint32），用binary.Write(w, order, len) - 再写内容字节：
binary.Write(w, order, []byte(s))，注意传的是切片，不是字符串本身
读取时也必须严格按此顺序还原：先读长度，再按该长度分配 []byte，最后用 io.ReadFull 填满。漏读、读错长度、或后续字节数不足，都会导致解析偏移或静默错位。
字节序不匹配会导致数值完全翻转，不是“差一点”
写入用 binary.BigEndian，读取却用 binary.LittleEndian，结果不是小误差，而是整个值颠倒。比如写入 uint16(0x1234)，大端存为 [0x12, 0x34]，小端读会当成 0x3412（13330），而非 4660。
常见错误现象包括：
-
binary.Read返回io.ErrUnexpectedEOF或明显异常值（如长度字段超大、时间戳为负） - 抓包看到原始 hex 是
00 00 00 01→ 对应 uint32 = 1 → 协议用大端 → 必须用binary.BigEndian - Python 的
struct.pack('iih')默认小端，Go 端必须严格匹配，不能靠“试”
别依赖 runtime.GOARCH 判断字节序：x86_64 是小端，但协议可能强制大端；ARM 可能是任一种，跟 Go 运行时无关。
struct 直接读写需字段导出、定长、无 padding
binary.Read 和 binary.Write 对 struct 是零容忍的：字段必须首字母大写（导出）、类型必须是定长（uint32 而非 int）、结构体内不能有编译器插入的 padding 字节。
否则会出现：
- 未导出字段被跳过，导致后续字段全部错位
- padding 字节被当成有效数据读入，数值乱套
- 混用
int和int32导致大小不一致，跨平台行为不可控
推荐做法是显式定义协议结构体，只含导出字段，并用 uint16/int32 等明确宽度类型。必要时加 // +build ignore 注释提醒对齐要求。
binary.Read 直接读 net.Conn 必然失败
TCP 是字节流，而 binary.Read 要求“刚好一包”的完整数据。直接把 net.Conn 传给它，大概率返回 0、极大随机数或 io.ErrUnexpectedEOF，根源不是代码写错，而是协议层根本没对齐。
必须先解决粘包和长度校验：
- 用
io.ReadFull替代裸Read，确保 header 读满再 decode - 先读固定头（如 6 字节），从中提取 payload 长度，再按需分配 buffer
- 对变长字段，务必做长度防护（如
if nameLen > 1024 { return err }），防 OOM
测试时别用 bytes.Buffer 模拟——它不会返回 partial read，会掩盖真实网络场景下的问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
