protobuf序列化生成二进制字节流，依赖字段编号而非名称或顺序，必须严格匹配.proto定义与生成代码；字段编号错位、版本不一致或手动反射拷贝均会导致解析失败或数据丢失。
Protobuf序列化不是JSON，它不存字段名
Go 里用 proto.Marshal 序列化后得到的是二进制字节流，不是可读文本。字段名、类型信息全被编译时抹掉，只保留 tag 编号 + 值。所以你不能靠“看数据”猜结构，必须依赖 .proto 文件和生成的 Go struct。
- 常见错误现象：
proto.Unmarshal返回unexpected EOF或invalid wire format—— 很大概率是发送方和接收方用的不是同一版.proto，或 struct 字段 tag 编号对不上 - 使用场景：跨服务通信、日志批量写入、本地缓存（比如把高频查询结果序列化后存
map[string][]byte） - 参数差异：
proto.Marshal不接受选项；想控制是否忽略零值，得在.proto里加[(gogoproto.nullable) = false]这类扩展，不是靠函数参数
struct 字段 tag 编号错一位，整个消息就废
Protobuf 解码完全依赖字段编号（1, 2, 3…），而不是字段顺序或名字。Go struct 的 json: tag 没用，真正起作用的是 protobuf: 后面的 number= 值。
- 常见错误现象：字段值莫名为零、字符串变空、嵌套 message 解析成 nil —— 先检查
protobuf:"bytes,5,opt,name=body"里的5是否和.proto中定义一致 - 性能影响：编号越小，编码后字节越短（单字节 varint），但别为了省几个字节乱排编号；重点是保持前后端一致
- 兼容性注意：新增字段必须用新编号，且不能复用旧编号；删除字段不能直接删 tag，得标成
reserved，否则老代码反序列化会 panic
指针字段和零值字段在 wire 上表现不同
Protobuf 区分“未设置”和“设为零值”。Go struct 中，*string 类型字段为 nil 表示未设置，"" 才表示设为空字符串。这点和 JSON 完全不同。
- 常见错误现象：前端传了空字符串，后端收到却是
nil—— 检查 proto 定义里字段是否用了optional（proto3 默认所有字段 optional，但生成的 Go struct 仍可能用指针） - 使用场景：需要精确表达“用户没填这个字段” vs “用户明确填了空”时，必须用指针类型 +
optional，并手动判断!= nil - 配置项：
protoc-gen-go的--go_opt=paths=source_relative不影响该行为，但--go-grpc_opt=require_unimplemented_servers=false之类和序列化无关，别混
别在 proto.Message 接口上做反射式深拷贝
proto.Clone 是唯一安全的复制方式。自己用 reflect 遍历 struct 字段、递归 copy，大概率漏掉内部的 XXX_* 隐藏字段（比如 XXX_unrecognized），导致后续 Marshal 出错或丢失未知字段。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：
proto.Unmarshal成功，但再Marshal出去后对方收不到某些字段 —— 可能是 copy 时丢掉了XXX_unrecognized - 实操建议：所有需要副本的地方，统一走
proto.Clone(msg).(YourMsgType)；如果担心性能，先确认瓶颈真在这里（通常不是） - 兼容性影响：不同版本
google.golang.org/protobuf对XXX_*字段的处理逻辑有微调，手写反射 copy 几乎必然跨版本失效
Protobuf 序列化的坑不在语法，而在“看不见”——没字段名、没类型标记、没运行时校验。最常出问题的，是团队里有人改了 .proto 却忘了同步更新生成代码，或者测试时用的 mock 数据恰好绕过了某个字段路径。
