Protobuf消息设计：多平级字段与嵌套子消息哪个更优？

作为踩过不少Protobuf结构设计坑的开发者，我来给你唠唠这个问题——当你要设计一个包含50+字段的消息时，按业务逻辑组织嵌套子消息绝对是更靠谱的选择，平级堆字段只适合那种字段少到一只手数得过来的简单场景。

为什么优先选嵌套结构？ #

• 可读性与可维护性拉满：50多个字段堆在一个消息里，后续你或者其他同事要找某个字段，得翻半天列表，新增或修改字段时还容易误操作到其他业务模块的字段。按业务逻辑分组（比如把用户信息、订单详情、物流信息各自做成子消息），一眼就能定位到对应的模块，维护起来省心太多。
• 扩展性更强：如果后续某个业务模块需要新增字段，直接在对应的子消息里加就行，不用在平级列表里挤位置，也不会打乱原有字段的编号逻辑。比如要给用户信息加个邮箱字段，直接在UserInfo里加，完全不影响订单或物流相关的字段。
• 语义更清晰：嵌套结构本身就传递了字段之间的业务关联，比如UserInfo子消息里的name、age、phone显然是一组相关数据，比平级的user_name、user_age更直观，新接手的开发者一看就懂。

两种结构的性能差异到底有多大？ #

很多人会担心嵌套会不会拖慢性能，其实在绝大多数日常业务场景里，这点差异真的可以忽略不计，原因如下：

• Protobuf的序列化/反序列化机制是基于字段编号的，不管是平级还是嵌套，底层都是逐个解析字段，嵌套只是多了一层“进入子消息”的操作，这部分的性能开销微乎其微，远不如字段类型（比如长字符串 vs 固定长度数值）、数据量大小带来的影响大。
• 从序列化后的字节大小来看，嵌套结构并不会额外增加太多开销——子消息本身只是一个带编号的字段，内部的字段依然是紧凑编码，和把这些字段平级放置的总字节数几乎没有区别。
• 极端场景下（比如每秒百万级别的序列化/反序列化），可能平级结构会有极其微弱的优势，但这种场景非常少见，而且相比可维护性的损失，这点性能提升完全不值得。

示例对比 #

平级结构（不推荐） #

message OrderMessage {
  // 用户信息相关
  string user_name = 1;
  int32 user_age = 2;
  string user_phone = 3;
  // 订单详情相关
  string order_id = 4;
  double order_amount = 5;
  int64 create_time = 6;
  // 物流信息相关
  string logistics_company = 7;
  string tracking_number = 8;
  // ... 还有40+个字段，越往下越混乱
}

嵌套结构（推荐） #

message OrderMessage {
  UserInfo user_info = 1;
  OrderDetail order_detail = 2;
  LogisticsInfo logistics_info = 3;
  // 其他业务模块子消息按需添加...
}

message UserInfo {
  string name = 1;
  int32 age = 2;
  string phone = 3;
  // 后续新增用户相关字段直接在这里加
}

message OrderDetail {
  string order_id = 1;
  double amount = 2;
  int64 create_time = 3;
}

message LogisticsInfo {
  string company = 1;
  string tracking_number = 2;
}

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