gob.Encoder写文件出错主因是未正确处理文件I/O：须用os.Create获取有效句柄、检查错误、编码后调file.Close()刷盘；且结构体字段必须首字母大写才可导出序列化，小写字段被静默忽略。
为什么直接用 gob.Encoder 写文件会出错？
常见错误是调用 gob.NewEncoder 后直接写入未打开的文件句柄，或忘记关闭 *os.File，导致数据没刷到磁盘、文件为空甚至 panic。Go 的 gob 包不自动处理底层 I/O 错误，必须显式检查 Close() 和 Encode() 的返回值。
正确做法是先用 os.Create 获取可写文件句柄，再传给 gob.NewEncoder；编码完成后必须调用 file.Close()，否则缓冲区内容可能丢失。
-
os.Create返回的*os.File必须检查 err，不能忽略 - 不要对同一个
*os.File多次调用gob.NewEncoder，每个 encoder 应独占一个 writer - 如果结构体字段名首字母小写（即 unexported），
gob无法序列化——这是最常被忽略的坑
结构体必须满足哪些条件才能被 gob 正确编码？
gob 只能序列化导出（首字母大写）字段，且类型必须是 Go 原生支持的：基本类型、指针、切片、map、struct、interface{}（运行时需具体类型）、channel 和 function（仅限 nil）。嵌套结构体也必须全部字段导出。
例如：type User struct { Name string; age int } 中 age 不会被保存；而 Age int 才行。另外，struct 不能包含不可比较类型（如 map、slice）作为 map key，否则编码时 panic。
立即学习“go语言免费学习笔记（深入）”；
- 所有需要持久化的字段必须首字母大写
- 避免在 struct 中嵌入非导出匿名字段，它们不会被编码
- 如果用了
time.Time，没问题；但自定义类型需实现GobEncode/GobDecode方法
如何安全地保存和读取本地 .gob 文件？
写入和读取必须成对使用 gob.NewEncoder / gob.NewDecoder，且读取时目标变量类型必须与写入时完全一致（包括包路径）。类型不匹配会导致 gob: type mismatch 错误。
示例写入：
file, err := os.Create("data.gob")
if err != nil {
log.Fatal(err)
}
defer file.Close()
enc := gob.NewEncoder(file)
err = enc.Encode(user) // user 是导出字段的 struct 实例
if err != nil {
log.Fatal(err)
}
示例读取：
file, err := os.Open("data.gob")
if err != nil {
log.Fatal(err)
}
defer file.Close()
dec := gob.NewDecoder(file)
var u User
err = dec.Decode(&u)
if err != nil {
log.Fatal(err)
}
- 读取前确保文件存在且非空，否则
Decode会返回EOF或unexpected EOF - 不要复用同一个
*gob.Decoder解码多个值，除非明确知道它支持流式解码 - 如果程序升级后修改了 struct 字段，旧
.gob文件可能无法反序列化——gob没有字段兼容性机制
有没有比 gob 更适合本地持久化的替代方案？
gob 是 Go 原生、高效、二进制紧凑，但只适用于 Go 程序间交换，不具备跨语言或向后兼容能力。如果你需要调试查看内容、做版本迁移或与其他系统交互，JSON 或 YAML 更合适。
性能上，gob 编码/解码通常比 json.Marshal 快 2–5 倍，内存占用更低；但 JSON 文件可读、易 diff、支持部分字段缺失（通过 omitempty 和默认零值处理）。
- 纯 Go 工具链 + 性能敏感 → 用
gob - 需要人工检查、Git 跟踪、API 对接 → 选
json - 配置类数据、带注释 →
yaml（需第三方库如gopkg.in/yaml.v3）
真正麻烦的是混合场景：比如你今天用 gob 存用户数据，明天想加个 Web 管理界面查数据——这时候就得现场写转换逻辑，或者干脆一开始就不该选 gob。
