Protobuf字段编号修改会导致数据错乱或丢弃，必须同步上下游；新增字段需显式声明optional；废弃字段用reserved保留；反序列化必须设DiscardUnknown=false以保障兼容性。
字段编号改了就废，不是警告是事实
Protobuf二进制格式不带字段名，只靠field number定位数据。一旦你把user_id = 1改成user_id = 2，旧客户端收到新服务发来的数据时，会把值塞错位置，或直接丢弃——更危险的是静默错乱，比如把int32当string解析。
这不是Go语言的问题，是Protobuf协议层硬约束。Go的proto.Unmarshal完全遵循它。
- 编号修改 = 协议重定义，必须同步所有上下游服务的
.proto和生成代码 - CI流程里建议加校验：
protoc --print-free-field-numbers user.proto检查编号是否重复/越界 - 高频字段（如
id、status）务必压在1–15，Go生成器不帮你优化，手动控制才省字节
新增字段必须optional，别信“默认就是可选”
Protobuf v3虽弃用required，但新增字段若没显式声明optional（v3.12+支持），或没确保生成器版本足够新，旧客户端解析时字段值为零值（0、""、nil）。业务逻辑若没做零值防护，就会出错。
- 新增字段一律用
optional修饰，例如：optional string email = 3; - 避免在Go struct上加非零JSON tag（如
json:"timeout,default=30"），proto不认这个 - 真正需要默认逻辑的，写在业务层：
if req.GetTimeout() == 0 { req.Timeout = 30 }
删字段？别删，reserved才是正解
直接从.proto里删除字段，会导致旧服务反序列化新数据时panic——runtime尝试访问已不存在字段的内存偏移，常见报错：panic: reflect: call of reflect.Value.Interface on zero Value。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 废弃字段必须用
reserved占位：reserved 3;或reserved "email"; - 预留要提前做，别等v2想加字段才发现编号被占；推荐v1就写
reserved 16 to 20; - Go生成代码里不会出现
reserved对应字段，但它能防止编译器误分配，也影响XXX_Unrecognized行为
unknown fields不能丢，DiscardUnknown=false是底线
旧版github.com/golang/protobuf默认丢弃未知字段，新版google.golang.org/protobuf默认保留——这是向后兼容的关键。但如果你用了proto.UnmarshalOptions{DiscardUnknown: true}，等于主动放弃兼容能力。
- 反序列化必须用：
opt := proto.UnmarshalOptions{DiscardUnknown: false} - 检查是否收到新字段：
if len(msg.XXX_Unrecognized) > 0 { log.Warn("received unknown fields") } - 线上可打点统计
len(msg.XXX_Unrecognized)，作为灰度升级依据 - 别手动清空
XXX_Unrecognized，否则升级后历史数据里的新字段就丢了
最易被忽略的其实是reserved的时机和DiscardUnknown的开关——它们不报错，但一上线就埋雷。字段编号和类型变更的约束倒是很刚性，反而容易守住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
