gob仅适用于同一版本Go程序间可信的短期数据传输；它不跨语言、无版本兼容性、要求字段导出且类型提前注册，结构变更易导致panic。
Go 的 encoding/gob 不适合跨语言或长期存储，只应在可信的 Go 进程间传递结构化数据。
什么时候该用 gob 而不是 json 或 protobuf
gob 是 Go 原生二进制序列化机制，特点是：类型信息随数据一起编码、不依赖 schema 定义、支持私有字段（只要可导出）、能直接序列化 channel/function/map 等复杂类型（但反序列化时有约束）。它唯一合理场景是：同一版本 Go 程序内部或相互信任的 Go 服务之间做短期内存/网络传输。
- 不用写 schema，结构体改字段名或增删字段后，老版本程序可能 panic（
gob: type not found或field mismatch） - 无法被 Python/Java 解析；
json更通用，protobuf更紧凑且跨语言 - 对浮点数、NaN、+Inf/-Inf 的处理不兼容 IEEE 754 标准，不同 Go 版本行为可能微调
gob 序列化必须满足的三个条件
否则运行时会 panic 或静默失败：
- 结构体字段必须以大写字母开头（即 exported），否则会被忽略 ——
gob不会报错，但字段值不会写入 - 结构体必须有无参构造能力（反序列化时用
reflect.New创建零值实例），不能依赖自定义构造函数 - 所有嵌套类型（包括 map key/value、slice 元素、interface{} 实际值）都必须是
gob支持的类型，例如：time.Time可以，sql.NullString默认不行（需注册gob.Register）
如何安全地用 gob 处理 interface{} 和自定义类型
gob 对 interface{} 的处理很特殊：它只保存运行时具体类型的值，反序列化时也必须提前注册该类型，否则报 gob: unknown type id or name。常见做法：
立即学习“go语言免费学习笔记（深入）”；
- 在程序启动时统一调用
gob.Register(&MyStruct{})或gob.Register(MyStruct{})（推荐传指针，避免值拷贝） - 如果要用
interface{}存多种类型，建议封装一层带 type tag 的 struct，而不是裸用interface{} - 自定义类型（如
type UserID int64）默认可序列化；但带方法或非标准底层类型的别名（如type Status uint8加了 String() 方法）最好显式Register
示例：
var buf bytes.Buffer
enc := gob.NewEncoder(&buf)
gob.Register(&User{})
enc.Encode(&User{Name: "Alice"}) // 必须先 Register 才能 Encode interface{} 值
为什么 gob 反序列化后切片长度为 0 或字段为空
最常见原因是：目标变量未初始化为指针，或接收变量类型与编码时不一致。例如：
- 错误写法：
var u User; dec.Decode(&u)→ 正确，但若写成dec.Decode(u)（传值）则解码失败且无提示 - 结构体字段类型变更（如
Age int→Age *int），旧数据无法自动转为指针，解码后为 nil - 使用
map[string]interface{}接收时，gob会按 runtime 类型还原，但若原始是map[string]string，反序列化后仍是map[string]string，不会变成interface{}
调试建议：用 gob.NewDecoder(bytes.NewReader(buf.Bytes())).Decode(&v) 后立刻检查 err，不要忽略返回值。
真正麻烦的是类型演化——gob 没有版本迁移机制，加字段容易，删字段或改类型基本只能停服升级。如果业务需要向前兼容，别碰 gob。
