gob编码私有字段会静默丢弃，因Go反射规则限制仅导出字段（首字母大写）可被访问；未导出字段如name、token被跳过，Decode后全为零值且无报错，字节数异常偏小。
gob 编码私有字段会静默丢弃，不是 bug，是 go 反射规则决定的——它根本看不到小写字母开头的字段。
为什么 gob.Encode 后字段值全为零
常见错误现象：Decode 后结构体字段全是零值（""、0、nil），但没报错；用 len() 检查编码后的字节数，发现异常偏小。
根本原因：gob 依赖反射读取字段值，而 Go 规定只有首字母大写的导出字段才能被包外代码（包括 gob.Encoder）访问。小写字段如 name、token、cacheData 全部被跳过，不编码也不报错。
- 改结构体定义是最简单方案：把
name string改成Name string - 如果结构体来自第三方库或不能动（比如
http.Request的某个嵌套私有字段），这条路就走不通 - 嵌套结构体要逐层检查：哪怕顶层字段导出了，中间某一级用了小写字段，整条链就断了
用 GobEncode/GobDecode 手动接管序列化
这是唯一能保留私有字段语义又完成序列化的办法，但必须自己负责状态完整性和类型注册。
使用场景：封装敏感字段（如加密后的 sessionToken）、内部缓存状态、需压缩后再传输的字段。
- 返回的
[]byte必须能被gob.Decode还原，建议统一用gob.NewEncoder编码一个临时代理结构体（全导出字段） -
GobDecode开头必须清空接收者状态，否则旧切片可能append而非覆盖，导致数据叠加 - 如果代理结构体里用了自定义类型（比如
type EncodedData []byte），必须提前调用gob.Register(EncodedData{})，否则运行时报gob: unknown type id or corrupted data - 别在
GobEncode里直接返回&s.privateField——gob不处理未导出字段的地址，会 panic
容易被忽略的兼容性雷区
gob 的跨版本兼容性极差，这点比 JSON 或 Protocol Buffers 严苛得多。
- 字段增删改名后，老版本程序解码新数据大概率 panic，且错误信息模糊（常是
invalid type或corrupted data） -
gob完全忽略 struct tag（比如`gob:"foo"`无效），字段名变更即断裂 - 即使只改了字段类型（比如
int→int64），也需同步更新所有上下游服务，无法灰度 - 如果用
GobEncode返回加密字节流，解密失败时GobDecode不会报错，而是静默填零——得靠业务层校验
