gob仅限同版本go程序间使用，要求结构体定义完全一致；interface{}字段需显式注册具体类型；小写字段被静默忽略；encoder/decoder非线程安全，须每次新建实例。
gob 不是通用序列化协议，它只在纯 Go 环境、同版本、结构体定义完全一致的前提下才可靠工作；用错场景（比如存数据库、跨语言通信、长期持久化）会直接导致解码失败或静默丢字段。
为什么 gob.Decode 会报 EOF 或 “type mismatch”
这不是流读完了，而是类型信息对不上。gob 在 Encode 时把完整类型路径（包名 + 结构体名 + 字段顺序 + 是否导出）都写进二进制流了，Decode 端只要有一点不匹配，就提前终止并报 EOF 或类型错误。
- 确认包路径是否一致（
myapp.User和other.User是两个类型） - 字段名大小写必须严格一致（
Name≠name） - 字段顺序不能变——加字段只能加在末尾，删字段会导致旧数据 decode 失败
- 小写字段被静默忽略，既不报错也不编码；看到“成功 encode”但值是零值，大概率是这个原因
- 如果用
net.Conn传，发送方没调conn.CloseWrite()，接收方会一直等EOF；建议改用消息边界（如先写长度）或每次Encode/Decode后flush
interface{} 字段 panic：“cannot encode unregistered interface” 怎么办
gob 遇到 interface{} 或自定义接口时，无法在运行时推断具体类型，必须提前注册所有可能的实际类型。
- 注册的是具体类型，不是接口本身：
gob.Register(&User{})、gob.Register([]Post{})、gob.Register(map[string]*Config{}) - 注册必须在创建
Encoder或Decoder之前完成，且收发两端注册顺序和类型要完全一致 - 嵌套接口（如
Data interface{}）要注册其所有可能的底层类型，一个都不能漏 - 别注册匿名 struct —— 每次编译生成的 type ID 不同，跨进程必失败
- 注册
new(T)返回指针，但如果实际值是值类型（如User{}），注册不匹配照样 decode 失败
gob.Encoder 和 gob.Decoder 为什么不能复用
Encoder 和 Decoder 都不是 goroutine-safe，内部维护类型缓存和流状态，跨请求混用会导致粘包、类型污染甚至 panic。
- 每个 TCP 连接应配一对独占的
Encoder/Decoder，不要在长连接中反复Encode(req)而不清空状态 - 不要把
Encoder当成全局单例注入多个 handler；每次 RPC 请求应新建，或至少确保线程/协程独占 - 若用
bytes.Buffer做缓冲，记得每次 encode 前buf.Reset()，否则残留数据会干扰下一次 decode -
gob的类型表（type table）在首次 encode 同一类型时写入头部，适合长连接复用；但状态不可跨请求共享
最常被忽略的一点：gob 不解析任何 struct tag（比如 gob:"-" 或 json:"name" 完全无效），字段是否参与序列化只取决于首字母是否大写。想跳过字段，唯一方式是让它非导出；想保留小写语义，必须实现 GobEncode/GobDecode 接口自行控制字节流。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
