gob.Encode panic 因 io.Writer 或指针字段为 nil；Decode 失败因类型不匹配、字段顺序/包路径不一致；[]byte 可用，map[string]interface{} 不支持。
gob.Encode 为什么总 panic：nil pointer dereference
因为 gob.Encoder 要求传入的 io.Writer 不能为 nil，且被编码的结构体字段若含指针，其指向值也不能为空（除非字段加了 omitempty 标签，但 gob 不支持该标签）。常见于直接传 nil 的 *bytes.Buffer 或忘记初始化结构体嵌套字段。
- 务必检查
encoder := gob.NewEncoder(w)中的w是否已初始化（如var buf bytes.Buffer） - 结构体中所有导出字段（首字母大写）都会被编码；若字段是
*T类型，必须确保它不为nil，否则 panic - gob 不识别 struct tag（比如
json:"-"），加了也没用；想跳过字段，只能让它非导出（小写开头）
gob.Decode 读不到数据或报 EOF：流没对齐或类型不匹配
gob 是二进制流协议，Encode 和 Decode 必须成对使用，且解码端的变量类型必须和编码端**完全一致**（包括包路径、字段顺序、是否导出），否则会静默失败或提前 EOF。
- 不要用
gob.NewDecoder(r).Decode(&v)解码到局部变量再返回——如果r是复用的连接（如 TCP conn），记得每次 decode 前确认流位置正确 - 编码端是
type User struct{ Name string }，解码端就不能是type UserInfo struct{ Name string }，即使字段一模一样也不行 - 如果用
net.Conn传 gob，务必在发送方调用conn.CloseWrite()或双方约定消息边界，否则接收方可能一直等不到 EOF
跨进程传递结构体时，为什么接收端 struct 多个字段就 panic
gob 在 encode 时会把类型信息（包括字段名、类型名、包名）一起写入流；decode 时靠这些信息重建结构。一旦接收端 struct 字段数、类型、顺序或包路径不同，gob 就无法对齐，轻则跳过字段，重则 panic: “cannot decode into nil pointer” 或 “type mismatch”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 两个程序必须共用同一份 struct 定义（建议抽成独立包，如
shared/model），不能各自 copy 一份 - 新增字段可以，但要加在末尾，且类型兼容（比如从
int改成int64不行）；删字段会导致旧数据 decode 失败 - 字段名大小写必须严格一致——
Name和name是两个字段，gob 不做映射
用 gob 传 []byte 或 map[string]interface{} 会出什么问题
[]byte 可以直接 encode/decode，但 map[string]interface{} 不行：gob 要求 interface{} 的具体类型在 encode 时已知，而空接口在运行时无类型信息，decode 时无法还原。
立即学习“go语言免费学习笔记（深入）”；
- 别传
map[string]interface{}，改用具体 struct（如map[string]string或map[string]User） -
[]byte没问题，但注意它底层是 slice，编码后体积和原始字节一致，不压缩 - 如果需要动态结构，先用
json.RawMessage序列化成字节，再用 gob 包一层——但这就绕远了，不如直接用 JSON
gob 的强约束性恰恰是它的安全边界：它不猜意图，只认签名。一旦结构体定义漂移，失败就是立刻的、明确的，而不是运行很久才错。
