gob.encode panic "nil pointer dereference"的根本原因是io.writer为nil或结构体导出指针字段值为nil；w必须是非nil可写对象（如bytes.buffer），且*t类型字段必须非nil，因gob不支持omitempty标签。
gob.Encode 为什么一调用就 panic: "nil pointer dereference"
根本原因不是结构体本身为 nil，而是 gob.Encoder 依赖的 io.Writer 为空，或待编码结构体中存在未初始化的导出指针字段。
-
gob.NewEncoder(w)的w必须是非 nil 的可写对象，比如bytes.Buffer{}或已建立的net.Conn；直接传nil或未var buf bytes.Buffer就 panic - 结构体里有导出指针字段（如
User *UserInfo），但该指针值为nil—— gob 会尝试解引用它，立刻崩溃；即使加了json:",omitempty"也没用，gob 完全忽略 struct tag - 私有字段（小写开头）被静默跳过，不是 panic 原因，但容易误判为“字段丢了”，实际是根本没编码
Decode 失败却不报错，只得到零值？检查类型一致性
gob 是强类型协议，Decode 不做容错映射，类型不一致时往往静默失败或提前 EOF，而不是明确报错。
- 编码端是
type User struct{ Name string }，解码端必须用**完全相同定义**的User类型：包路径、字段名大小写、字段顺序、是否导出，缺一不可 - 哪怕只是把接收端结构体重命名为
UserInfo，哪怕字段一模一样，也会 decode 失败；更别说跨 package 时路径不同（myapp.User≠otherpkg.User） - 新增字段只能加在末尾，且类型要向后兼容（
int→int64不行；string→string可以）；删字段会导致旧数据 decode panic
想传 map[string]interface{} 或第三方类型？别硬来，换结构
map[string]interface{} 和未导出/未注册的第三方类型（如 *ratelimit.Bucket）无法被 gob 正确 decode，结果常是空 map 或 panic。
-
map[string]interface{}在 encode 时没有运行时类型信息，decode 端无法还原具体类型；改用明确结构体，例如map[string]RateLimitConfig - 第三方包里的非导出类型，gob 既不能自动推断结构，也无法注册（
gob.Register要求类型可导出）；应提取核心字段，定义自己的等效结构体 - 若必须传接口（如
interface{}），必须提前用gob.Register(&User{})注册所有可能的具体类型，且注册要在NewEncoder/NewDecoder之前完成，两端一致
TCP 上用 gob，不加帧头等于裸奔
gob 本身不带消息边界，直接套在 net.Conn 上，遇到网络抖动、半包或粘包，Decode() 就会卡住或返回 io.ErrUnexpectedEOF，且 decoder 实例不可复用。
- 必须自己实现帧封装：每个消息前写 4 字节大端长度（
binary.BigEndian.PutUint32(buf[:], uint32(dataLen))），接收端先读长度，再读对应字节数交给gob.Decoder - 不要复用同一个
gob.Encoder多次Encode()到长连接——它内部缓存类型信息，跨请求可能污染 decoder 端解析；推荐每个逻辑消息新建 encoder/decoder，或至少确保独占使用 - 每次
Decode(&v)的&v必须是非 nil 指针；若v是局部变量，需确认其生命周期覆盖整个 decode 过程
gob.Encode，而是在类型演化、跨进程部署、网络不稳定这些现实约束下，让二进制流始终可解、可扩、可维护。字段改名、包路径迁移、新增可选字段——这些日常操作，在 gob 里都得当心。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
