为什么不用 gob 直接存 map[string]interface{}
因为 gob 要求类型在编码/解码时完全一致，而 map[string]interface{} 中的 interface{} 会丢失具体类型信息——写入时是 int64，读出来可能变成 float64（尤其从 JSON 过来的数据），导致后续类型断言失败或数值异常。
更麻烦的是，gob 不支持对已存在文件做“追加写”或“局部更新”，每次保存都得全量序列化整个 map，小数据还行，一旦 KV 超过几千条，I/O 和内存开销就明显了。
gob 编码前必须注册自定义类型
如果你的 value 是结构体（比如 User、Config），不注册就 panic：gob: type not registered for interface: main.User。注册不是可选动作，是强制前提。
- 在程序启动早期（如
init()或main()开头）调用gob.Register(&User{})，注意传指针 - 如果 value 类型可能动态变化（比如不同业务存不同 struct），得提前把所有可能类型都注册一遍，漏一个就会在解码时崩溃
- 注册类型必须和解码时的包路径完全一致；跨 package 使用时，别用
import . "xxx"简写，否则注册的类型名和实际反序列化的不匹配
文件级并发安全不能靠 gob 自己解决
gob.Encoder 和 gob.Decoder 本身不是并发安全的，但更大的问题是：多个 goroutine 同时读写同一个文件，会导致内容错乱或 unexpected EOF 错误。这不是 gob 的 bug，是文件系统层面的竞争。
- 必须用
sync.RWMutex控制读写互斥：读操作用RLock()，写操作用Lock() - 不要尝试用
O_APPEND模式追加gob数据——gob文件不是日志，没有分隔符，连续 decode 会失败 - 如果真需要高并发写入，考虑先写入临时文件 +
os.Rename()原子替换，再配合内存缓存减少落盘频次
小文件场景下，gob 比 JSON 更快但更难调试
二进制格式让 gob 序列化/反序列化速度通常比 JSON 快 2–3 倍，文件体积也小 30% 左右。但坏处是：你没法直接 cat db.gob 看内容，出问题时只能靠打印日志或写辅助解码工具。
- 开发期建议加一层 wrapper：写入前用
json.Marshal打日志（仅 debug 环境），确认数据结构符合预期 - 避免在
gob文件里存含func、channel、unsafe.Pointer的值，它们无法被编码，运行时报gob: type not supported - 版本升级时若修改了 struct 字段（比如删掉一个字段），老文件仍能 decode，但新字段为零值；若新增字段并希望兼容旧数据，需实现
GobEncode/GobDecode接口自行控制
真正卡住人的往往不是怎么写进去，而是某天发现文件损坏后，连“里面到底有没有那条 key”都确认不了——所以定期校验 + 备份原始数据结构定义，比优化序列化性能重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
