proto.Unmarshal 是唯一推荐的解码入口，必须使用 v2 API（google.golang.org/protobuf），禁用已弃用的 github.com/golang/protobuf/proto；需显式配置 proto.UnmarshalOptions 控制未知字段，严格校验二进制数据格式与来源。
proto.Unmarshal 是唯一推荐的解码入口
直接调用 proto.Unmarshal，别自己解析 wire format。Go 官方 protobuf 库（google.golang.org/protobuf）已彻底弃用旧版 github.com/golang/protobuf/proto，新项目必须用 v2 API，否则会遇到 silent fail、零值不还原、嵌套消息 panic 等问题。
- 旧写法
proto.Unmarshal(data, &msg)（v1）在 proto3 下对未设置字段返回零值，但无法区分“显式设为 0”和“根本没传”，且不支持optional字段语义 - 新写法必须用
proto.UnmarshalOptions{DiscardUnknown: false}显式控制未知字段行为，否则默认丢弃（尤其升级 proto 文件后老数据可能静默失效） - 如果二进制来自 C++ 或 Python 服务，注意对方是否启用了
serialize_partial—— Go 的Unmarshal不会报错，但缺失字段始终为零值，容易误判业务逻辑
二进制数据来源不对，Unmarshal 就会静默失败
常见错误是把 Base64 编码字符串、HTTP body 未经处理直接喂给 Unmarshal，或者误把 gRPC 的 Frame Header（前 5 字节）也混进去。它只认纯 protobuf wire format 二进制流。
- 确认数据开头不是
0x0a（常见于误加了 length-delimited wrapper）、也不是0x12（可能是被其他序列化层包了一层） - 用
hex.Dump(data[:min(len(data), 16)])快速看前几个字节：合法 protobuf 通常以 field tag（如0x08,0x12,0x1a）起始，且 wire type 在低 3 bit（0x00,0x02,0x05最常见） - 如果是从文件读取，确保没带 BOM；如果是从网络接收，确认 TCP buffer 没被截断（
len(data) 时不能硬解）
字段类型不匹配会导致解码成功但值错乱
Protobuf 不校验字段语义，只按 tag + wire type 解析。比如定义是 sint32，但发来的是 int32 wire type 0，Unmarshal 仍会成功，但 ZigZag 解码后数值翻倍或溢出。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
int32/uint32/sint32虽然 wire type 都是 0，但编码规则不同：sint32用 ZigZag，int32是原生变长整数 —— 二者混用必出错 - string 和 bytes 字段 wire type 同为 2，但 string 要求 UTF-8 合法；若传入非法字节，
Unmarshal不报错，后续msg.GetName()可能 panic 或返回空串 - repeated 字段若被当成 singular 解码（比如 tag 写错），会覆盖而非追加，导致只保留最后一个元素
调试时别只看 err != nil，要检查字段实际值
Unmarshal 返回 nil 只代表 wire format 合法，不代表业务数据可用。很多线上 bug 出在“解码无错，但关键字段是零值”。
立即学习“go语言免费学习笔记（深入）”；
- 对必填字段（即使 proto3 没 required），手动加校验：比如
if msg.GetId() == 0 { return errors.New("id missing") } - 启用
proto.UnmarshalOptions{Resolver: xxx}自定义 resolver，可在字段缺失时注入默认值或记录日志 - 用
proto.Equal对比已知正确样本，快速定位是协议定义偏差还是数据污染
真正麻烦的永远不是解码失败，而是解码成功却用错了字段含义——尤其当 proto 文件由多个团队维护、tag 号复用、或历史兼容字段堆积时。
