Proto3中字段封装为消息与标记可选的选型及兼容方案问询

注：以下内容均针对Protocol Buffers 3版本。

假设我们有如下初始消息定义：

message Foo {
  int32 weight_in_lbs;
}

消息生产者希望停止以磅为单位输出重量，改为以千克为单位，因此将磅单位字段标记为弃用，并新增千克单位字段：

message Foo {
  int32 weight_in_lbs [deprecated = true];
  int32 weight_in_kgs;
}

由于生产者为分布式部署（多服务器），无法一次性完成升级，因此会存在新旧版本消息同时产生的阶段。理想情况下消费者应同时检查weight_in_lbs和weight_in_kgs字段，优先使用后者，无后者时回退使用前者。但在Proto3中，无法区分字段是未被设置还是被生产者设置为默认值，官方文档给出两种方案：

1. 将字段封装到消息中，以便使用HasField()方法
2. 将字段标记为optional（官方不推荐）

两种官方方案的优劣对比 #

1. 字段封装到消息中（推荐方案）

• 实现方式：将重量字段封装为独立的嵌套消息，示例定义如下：

  message Weight {
    int32 value = 1;
  }
  message Foo {
    int32 weight_in_lbs [deprecated = true];
    Weight weight_in_kgs = 2;
  }
  

• 优势：完全符合Proto3的设计规范，通过HasField("weight_in_kgs")可以明确判断字段是否被生产者设置，不存在歧义，跨语言、跨版本兼容性强。
• 劣势：需要修改消息结构，消费者代码需适配嵌套字段的读取逻辑，比如从weight_in_kgs.value取值。

2. 标记字段为optional（不推荐）

• 实现方式：直接在新字段上添加optional修饰，示例定义如下：

  message Foo {
    int32 weight_in_lbs [deprecated = true];
    optional int32 weight_in_kgs = 2;
  }
  

• 优势：消息结构改动最小，消费者可直接通过生成的has_weight_in_kgs()方法判断字段是否被设置，代码适配成本低。
• 劣势：optional是Proto3为兼容Proto2引入的语法，不符合Proto3"默认值等价于未设置"的核心设计理念，长期来看可能存在跨语言或Protobuf版本兼容性风险，官方明确不推荐在新代码中使用。

第三种方案：使用官方包装类型 #

Protobuf提供了google.protobuf.Int32Value等官方包装类型，这类类型本身就是消息结构，天然支持HasField()判断，无需自定义嵌套消息：

import "google/protobuf/wrappers.proto";
message Foo {
  int32 weight_in_lbs [deprecated = true];
  google.protobuf.Int32Value weight_in_kgs = 2;
}

• 优势：复用官方标准类型，符合Proto3设计规范，兼容性强，同样能明确判断字段是否被设置，无需自定义嵌套消息。
• 劣势：需要引入官方包装类型的依赖，消费者代码需处理包装类型的取值逻辑，比如调用weight_in_kgs.getValue()获取实际数值。

当前消费者编程模式的潜在问题 #

如果不解决"无法区分未设置和默认值"的问题，直接读取两个字段并优先使用新字段的模式会存在逻辑歧义：
比如当生产者将weight_in_kgs设置为0（int32的默认值）时，消费者无法区分这个值是生产者主动设置的，还是字段未被设置时的默认值，会错误地回退到weight_in_lbs的取值，导致数据解析错误。只有当能明确判断新字段是否被生产者主动设置时，"优先新字段、回退旧字段"的模式才是可靠的。

内容的提问来源于stack exchange，提问作者distributer