Gob默认不序列化私有字段，仅编码首字母大写的导出字段；需通过GobEncode/GobDecode接口自定义处理私有状态，且须注意跨版本兼容性差、nil指针易panic等问题。
私有字段在 Gob 中默认不被序列化
Gob 只编码导出（首字母大写）的字段，这是 Go 的反射规则决定的——gob.Encoder 无法访问私有字段的值。你写个 type User struct { name string; Age int }，name 永远不会出现在编码结果里，哪怕你手动调用 Encode 也不会报错，只是静默忽略。
常见错误现象：解码后结构体字段全为零值，但没报错；或者日志里看到编码字节数特别小，明显不对。
- 必须把要序列化的字段名首字母大写，比如改
name为Name - 如果不能改结构体定义（比如第三方库类型），只能靠自定义
GobEncode/GobDecode方法中转 - 注意嵌套结构体：所有中间层级的字段都得导出，否则链路一断就丢数据
实现 GobEncode/GobDecode 自定义编码逻辑
当字段必须保持私有时，唯一办法是让类型实现 GobEncode 和 GobDecode 接口。这两个方法负责把私有状态转成一个临时的、全导出的代理结构体，再交给 Gob 处理。
使用场景：封装敏感字段（如 token、密码哈希）、内部缓存状态、或需要压缩/转换后再序列化的字段。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 返回的
[]byte必须能被gob.Decode正确还原，建议统一用gob.NewEncoder编码代理结构体 -
GobDecode必须先清空接收者状态，否则旧值残留（比如切片 append 而非重赋值） - 别在
GobEncode里直接返回私有字段指针——Gob 不处理未导出字段的地址，会 panic
示例：
func (u *User) GobEncode() ([]byte, error) {
type Alias User // 避免无限递归
buf := new(bytes.Buffer)
enc := gob.NewEncoder(buf)
err := enc.Encode(struct {
Name string
Age int
}{u.name, u.Age})
return buf.Bytes(), err
}
Gob 兼容性差，跨版本或跨服务慎用
Gob 不是稳定协议，Go 标准库不承诺向后兼容。同一段代码，在 Go 1.19 编码的数据，Go 1.22 可能无法解码，尤其涉及泛型、接口底层类型变更时。
性能影响：Gob 比 JSON/Protobuf 更快（无字符串解析开销），但体积通常更大（含类型信息），且不支持流式解码。
- 绝不要把 Gob 数据存进数据库或作为长期持久化格式
- 微服务间通信禁用 Gob——HTTP/gRPC 等协议栈默认不支持，且无法被其他语言解析
- 如果必须用，固定 Go 版本 + 在测试里加入 encode/decode round-trip 校验
nil 指针和 interface{} 值容易 panic
gob.Encoder 对 nil 指针或未初始化的 interface{} 会直接 panic，错误信息通常是 gob: type not registered for interface 或 nil pointer dereference，而不是明确说“你传了 nil”。
常见于：结构体字段是 *string 但没分配内存；函数返回 interface{} 却忘了赋值；map 中存了 nil 值。
- 编码前用
if v == nil显式检查指针字段 - 对
interface{}字段，注册具体类型：调用gob.Register((*string)(nil))等 - map/slice 字段为空时，优先用
make(map[K]V)而非var m map[K]V，避免 nil map panic
