gob.encode panic“nil pointer dereference”根本原因有两个：一是io.writer为nil（如未初始化的bytes.buffer），二是结构体导出指针字段值为nil（gob会解引用且忽略omitempty标签）。
gob 和 encoding/binary 是 Go 里处理二进制序列化的两个主力，但它们定位完全不同——选错就卡在 runtime panic 或静默丢数据上，不是语法问题，是设计误用。
gob.Encode 一调用就 panic: "nil pointer dereference" 怎么快速定位？
根本不在结构体本身是否为 nil，而在两个地方：io.Writer 和导出指针字段。
-
gob.NewEncoder(w)的w必须是非 nil 可写对象：比如bytes.Buffer{}、os.File或已建立的net.Conn；直接传nil或未初始化的变量（如只声明没var buf bytes.Buffer）立刻 panic - 结构体里有导出指针字段（如
User *UserInfo），但该指针值为nil——gob会尝试解引用它，不报错直接崩溃；加了json:",omitempty"没用，gob完全忽略 struct tag - 私有字段（小写开头）被静默跳过，不是 panic 原因，但容易误判为“字段丢了”，实际是根本没编码
binary.Write 对含 string 或 []byte 的 struct panic，为什么没提示？
encoding/binary 不做字段合法性检查，它只按 unsafe.Sizeof 写内存原始字节。遇到 string 或 []byte，写进去的只是 header（len/cap/ptr），不是真实内容。
- 典型现象：
panic: reflect.Value.Interface: cannot return unaddressable value，或反序列化后[]byte长度为 0 但cap很大，读出来是垃圾地址 - 能安全用
binary.Write的结构体：所有字段必须是定长类型，例如uint32、[16]byte、嵌套的定长 struct；type Msg { ID uint32; Body string }就不行 - 变长字段必须手动拆解：先写长度（如
binary.BigEndian.PutUint16(buf[pos:], uint16(len(data)))），再写内容（copy(buf[pos:], data)），且 buffer 要提前分配足量空间
Decode 失败却不报错，只返回零值？检查类型一致性
gob 是强类型协议，不做容错映射。类型不一致时往往静默失败或提前 io.ErrUnexpectedEOF，而不是明确报错。
- 编码端是
type User struct{ Name string }，解码端必须用**完全相同定义**的User类型：包路径、字段名大小写、字段顺序、是否导出，缺一不可 - 哪怕只是把接收端结构体重命名为
UserInfo，哪怕字段一模一样，也会 decode 失败；更别说跨 package 时路径不同（myapp.User≠otherpkg.User） - 新增字段只能加在末尾，且类型要向后兼容（
int→int64不行；string→string可以）；删字段会导致旧数据 decode panic
TCP 上直接套 gob，不加帧头等于裸奔
gob 本身不带消息边界，直接套在 net.Conn 上，遇到网络抖动、半包或粘包，Decode() 就会卡住或返回 io.ErrUnexpectedEOF，且 decoder 实例不可复用。
- 必须自己实现帧：常见做法是前置 4 字节长度头（
binary.BigEndian.PutUint32），读时先读长度，再按长度读完整 payload - 不要复用同一个
gob.Decoder实例处理多个消息；每次新消息都应 new 一个 decoder，或重置 buffer - 如果必须传
interface{}，必须提前用gob.Register(&User{})注册所有可能的具体类型，且注册要在NewEncoder/NewDecoder之前完成，两端一致
gob，该切 encoding/json 就切；但凡结构体里有 map[string]interface{} 或第三方类型（如 *ratelimit.Bucket），gob 就大概率给你空 map 或 panic —— 它不是通用序列化器，而是 Go 进程间高效通信的专用协议。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
