binary.Write 不能直接写 string，因 string 是变长类型，无固定字节长度，会 panic；正确做法是先写长度（如 uint16），再写 []byte(name)。
binary.Write 不能直接写 string，会 panic
试图用 binary.Write 直接写入 string 类型变量，运行时立刻 panic：panic: binary.Write: invalid type string。这不是类型不匹配的提示，而是包明确拒绝变长类型——string 没有固定字节长度，无法被“摊平”进连续二进制流。
常见错误写法：
-
binary.Write(w, binary.BigEndian, "hello")❌ -
binary.Write(w, binary.BigEndian, struct{ Name string }{"abc"})❌ 字段是小写或类型非法都会失败
正确做法是手动拆解：
- 先写长度（如
uint16或uint32），再写内容字节 - 内容必须转成
[]byte，再用binary.Write写入切片（注意：切片本身是定长类型，但只写元素，不写长度） - 示例：
name := "hello" binary.Write(w, binary.BigEndian, uint16(len(name))) // 写长度 binary.Write(w, binary.BigEndian, []byte(name)) // 写内容
读取字符串必须先读长度，再按长度读字节
反向操作更易出错：如果写入时用了长度前缀，读取时必须严格按顺序还原。漏读长度、长度读错、或后续读取字节数不足，都会导致解析偏移、panic 或静默错位。
立即学习“go语言免费学习笔记（深入）”；
典型陷阱：
- 用
binary.Read(r, order, &str)直接读string字段 → 编译不过或 panic - 读完长度后，用
io.ReadFull(r, buf)填充字节，但buf长度与长度字段不一致 →io.ErrUnexpectedEOF - 没检查长度是否过大（如超 64KB），可能分配巨量内存或触发 OOM
安全读取示例：
var nameLen uint16
err := binary.Read(r, binary.BigEndian, &nameLen)
if err != nil {
return err
}
if nameLen > 1024 { // 防护性检查
return fmt.Errorf("name too long: %d", nameLen)
}
buf := make([]byte, nameLen)
err = io.ReadFull(r, buf)
if err != nil {
return err
}
name := string(buf)
字节序不匹配会导致数值完全颠倒
写入用 binary.BigEndian，读取却用 binary.LittleEndian，结果不是“差一点”，而是整个值翻转。比如写入 uint16(0x1234)，大端存为 [0x12, 0x34]，小端读会当成 0x3412（即 13330），而非预期的 4660。
协议中只要出现“network byte order”“MSB first”“big-endian”等描述，就必须统一用 binary.BigEndian；本地文件或 Windows PE 资源常见小端，但绝不能靠 runtime.GOARCH 推断——ARM64 macOS 是小端，但协议仍可能要求大端。
建议：
- 把字节序定义为包级常量：
const Endian = binary.BigEndian - 所有
binary.Read/binary.Write调用都显式传该常量，避免硬编码散落各处 - 调试时打印原始字节：
fmt.Printf("%x", data)，对照协议文档逐字节核对
结构体字段必须导出且定长，否则静默跳过或 panic
binary.Write 和 binary.Read 对结构体只处理首字母大写的导出字段，且每个字段类型必须有确定字节长度。小写字段（如 id int32）会被跳过，值保持零值；int、[]byte、map 等类型直接 panic。
容易忽略的细节：
- 数组如
[32]byte是合法的，但[]byte不行——后者长度不固定 - 结构体字段顺序必须和协议定义完全一致，编译器不会重排，但 padding 字节会被当有效数据读入
- 别用
unsafe.Sizeof判断结构体大小——它包含 padding；应手动计算字段总和，或用github.com/edsrzf/mmap-go等工具校验
错误结构体示例：
type Bad struct {
magic uint32 // 小写 → 跳过
len int // 平台相关 → panic
name string // 变长 → panic
}
正确写法：
type Good struct {
Magic uint32
Len uint16
Name [32]byte // 固定长度，空位自动补 0
}
实际写协议解析逻辑时，最麻烦的从来不是字节序或长度前缀，而是字段对齐和 padding 的隐式干扰——它不会报错，但会让第 3 个字段开始全错。宁可不用结构体，分字段手写 binary.Read，也别赌编译器布局。 
