解读

在国内高并发、多团队协作的 PHP 微服务场景里，接口协议一旦上线就被大量客户端（App、小程序、H5、内部服务）依赖。Protobuf 作为强契约的 IDL，字段废弃若处理不当，极易引发“线上报错、数据错位、版本回滚”三连击。面试官问“最佳实践”，核心想确认两点：

1. 你是否理解 Protobuf 的“向后兼容”红线；
2. 你能否给出一条从“标记废弃”到“真正下线”可落地的、符合国内灰度节奏与 PHP 技术栈的完整路径。

知识点

1. Protobuf 的字段标识规则：
   • 115 占 1 byte，162047 占 2 byte，字段号永不复用；
   • 删除字段号会导致旧包解析异常，必须保留。
2. reserved 语法：proto3 中 reserved 9, 15, 20 to 25; reserved "old_name"; 可禁止字段号与名字被复用。
3. PHP 侧解析特性：
   • google/protobuf-php 与 gRPC 扩展在遇到未知字段时默认跳过，不会抛异常；
   • 但若用 JsonFormat::parse() 反序列化，缺失字段会赋默认值，可能把 0、'' 写入数据库，引发脏数据。
4. 国内灰度节奏：
   • 一般按“内部接口 → B 端 → C 端”三阶段灰度，周期 2~4 周；
   • 需同步输出“变更公告 + 埋点监控”，由配置中心开关控制。
5. 合规与审计：
   • 金融、出海业务需留痕，字段废弃要进入“数据字典”变更工单，防止监管扫描到敏感字段被删除。

答案

我给出的最佳实践分五步，已在公司 Laravel-gRPC 项目落地，线上稳定运行两年：

1. 标记废弃（Day 0）
   • 在 .proto 文件中给字段加 [(grpc.federation.field_deprecated).reason = "use new_user_id instead", deprecated = true];
   • 同时在注释里写“计划下线时间：2025-10-01”，让 IDE 产生 strikethrough 提示。
2. 保留字段号（永久）
   • 在 message 顶部写 reserved 7; reserved "extra_info"; 防止后人复用。
3. PHP 服务端双写（灰度期 2~4 周）
   • Laravel 事件监听器同时填充废弃字段与新字段，保证旧客户端不报错；
   • 通过 Envoy 的 traffic-splitting 把 5% 流量打到“只读新字段”版本，观察 Prometheus 中 grpc_client_handled_total{code="OK"} 是否下跌。
4. 客户端埋点与强制升级（灰度后）
   • 在 Response 里新增 server_version=2.0 头部，PHP 中间件记录 access log；
   • 运营在小程序后台配置“最低可用版本”，低于该版本弹窗强制更新。
5. 正式下线（灰度 30 天后）
   • 先注释掉 PHP 代码里的双写逻辑，保留字段号与 reserved；
   • 发版后观察 3 天无异常，再提交 proto 仓库 MR，把废弃字段彻底删除，但 reserved 语句永久保留。

整个流程用 GitLab CI 做自动化检查：如果 MR 里删除了字段号却没加 reserved，buf lint 会直接失败，从源头杜绝误操作。

拓展思考

1. 若字段属于“敏感数据”（如身份证），即使废弃也不能立即删，需先走“数据脱敏 + 法务评审”，再用 Protobuf 的 FieldMask 机制做白名单过滤，防止旧接口继续透出。
2. 对于 ToB 开放 API，可把废弃字段映射到 OpenAPI 的 deprecated: true，并在 Laravel 层通过 Transformation 把废弃字段值同步到新字段，实现“零感知”迁移。
3. 如果公司采用 GraphQL-gateway 聚合 gRPC，可在 GraphQL 层标记 @deprecated(reason: "use userV2")，利用 Apollo Studio 的字段级监控，等查询量降到 0 再真正下线，实现“双层废弃”防护。