Protobuf 字段删除后服务 panic：为什么不能直接删 optional 字段
Go 的 protoc-gen-go 生成代码默认不校验字段存在性，但 runtime 会尝试访问已删除字段的内存偏移——尤其当新 client 发请求给旧 server（或反之），而 .proto 中删了字段但二进制 wire 数据里还带着该字段时，Unmarshal 可能静默跳过，但后续 GetXXX() 调用会 panic。
真正安全的做法是「字段废弃」而非「物理删除」：
- 用
deprecated = true标记字段，并保留其 tag 编号（如12） - 在 Go 侧读取逻辑中显式忽略该字段，比如用
proto.HasExtension或检查proto.GetUnknownFields是否含该编号 - 确保上下游都升级到支持该 deprecated 语义的 protoc 版本（v3.15+）
示例错误日志：panic: reflect: call of reflect.Value.Interface on zero Value，往往就是访问了未设置的 optional 字段返回的 nil 指针。
新增字段导致 client 解析失败：必须设默认值且避免 required
Protobuf v3 已弃用 required，但很多团队误以为「加个新字段=加个非空字段」，结果旧 client（未更新 proto）收到带新字段的响应时，Unmarshal 成功，但字段值为零值（0、""、nil）——如果业务逻辑没做零值防护，就会出错。
立即学习“go语言免费学习笔记（深入）”；
正确做法是让新增字段天然可选，并提供语义明确的默认行为：
- 新增字段一律用
optional（v3.12+）或无修饰符（v3 默认就是 optional） - 避免在 Go struct 中给字段加非零初始值（如
Count int `json:"count,default=1"`），proto 不认 JSON tag - 真正需要默认逻辑的，应在业务层判断：
if req.GetTimeout() == 0 { req.Timeout = 30 }
注意：proto.UnmarshalOptions{DiscardUnknown: true} 可防止未知字段导致解析失败，但无法解决零值误用问题。
gRPC 接口签名变更：如何让新旧 service 同时跑在同一个端口
直接改 service 定义里的方法名或入参类型，会导致 gRPC Server 注册失败（duplicate method）或 client 调用 12-NotFound 错误。想灰度升级，得靠「共存」而非「替换」。
推荐方案是版本化 service 名称 + 路由分发：
- 定义新 service：
service UserServiceV2 { rpc GetUser(GetUserRequestV2) returns (GetUserResponseV2); } - 在 server 端同时注册
UserServiceServer和UserServiceV2Server - 用中间件（如
grpc.UnaryInterceptor）根据/UserService/GetUser或/UserServiceV2/GetUser的完整 method path 分流
别依赖 gRPC 的 UnknownServiceHandler 做 fallback——它只捕获未注册 service，不处理 method 级别兼容。
Go 的 proto.Equal 在版本混用时不可靠
两个 protobuf message 字段数不同，但业务上等价（比如旧版有 user_name，新版拆成 first_name + last_name），proto.Equal(a, b) 一定返回 false，哪怕你手动做了字段映射。
这时候必须绕过生成代码的结构比较：
- 写自定义比较函数，只比关键业务字段（如 ID、状态、时间戳）
- 用
proto.Marshal后做 bytes.Compare（仅限字段完全一致的场景，否则序列化顺序不同也会失败） - 更稳妥的是：在 RPC 层统一用
jsonpb（或protojson）转 map[string]interface{}，再按需 diff
容易被忽略的一点：protobuf 的 unknown fields 在 proto.Equal 中默认参与比较——哪怕你设了 DiscardUnknown: true，反序列化后的对象仍可能携带 unknown data，影响结果。
