Protobuf中建模字段关联对象：通用消息方案是否合规？

现有三类对象A、B和C：

• A和B共享部分字段，同时各自拥有独有字段
• C包含A和B的所有字段，还拥有一些额外的独有字段

显然可以通过为每个对象创建独立消息的方式在Protobuf中建模：

message A {
    uint32 A_B = 1;
    uint32 A_C = 2;
}

message B {
    uint32 A_B = 1;
    uint32 B_C = 2;
}

message C {
    uint32 A_B   = 1;
    uint32 A_C   = 2;
    uint32 B_C   = 3;
    uint32 onlyC = 4;
}

但我想知道，创建一个包含标识枚举的通用消息来表示这三类对象是否合理？

message Generic {
    enum Specific{
        A = 1;
        B = 2;
        C = 3;
    }
    Specific obj = 1;
    uint32 A_B   = 2;
    uint32 A_C   = 3;
    uint32 B_C   = 4;
    uint32 onlyC = 5;
}

我知道从技术角度两种方案都可行，但第二种方式是否不符合Protobuf的最佳实践？

注：这些对象代表不会变更的API调用参数列表

结论：第二种通用枚举方案不符合Protobuf最佳实践，更推荐优化后的独立消息方案 #

为什么不推荐通用枚举消息？ #

1. 丢失类型安全：调用方可能错误设置不属于当前枚举类型的字段（比如指定obj = A却填了B_C），Protobuf本身不会做校验，需要业务层额外处理，增加出错概率。
2. 序列化冗余：以A类型消息为例，B_C、onlyC等无关字段会被序列化为默认值，即便Protobuf会压缩默认值，长期来看也不如只序列化必要字段高效。
3. 可读性与维护性差：其他开发者阅读代码时，无法直接从消息结构判断字段归属，必须结合枚举值理解，提升了维护成本。
4. 扩展性受限：即便当前对象不会变更，未来若要新增字段或扩展类型，通用消息会越来越臃肿，独立消息的调整灵活性更高。

更优的独立消息方案（复用字段避免重复定义） #

既然A和B有共享字段，C包含两者所有字段，可以通过嵌套消息实现字段复用：

// 提取A和B的共享字段
message SharedAB {
    uint32 A_B = 1;
}

message A {
    SharedAB shared = 1;
    uint32 A_C = 2;
}

message B {
    SharedAB shared = 1;
    uint32 B_C = 2;
}

message C {
    A a_fields = 1;
    B b_fields = 2;
    uint32 onlyC = 3;
}

如果希望C的字段结构和原方案一致（平铺字段），也可以用嵌套消息的方式保持兼容性：

message A {
    uint32 A_B = 1;
    uint32 A_C = 2;
}

message B {
    uint32 A_B = 1;
    uint32 B_C = 2;
}

message C {
    A a = 1;
    B b = 2;
    uint32 onlyC = 3;
}

这种方案既保留了独立消息的类型安全，又避免了字段重复定义，完全符合Protobuf的设计理念。

结合你的场景（不可变更的API参数） #

即便API参数不会变更，独立消息方案依然更合适：

• 调用方直接使用对应类型的消息作为参数，无需额外判断枚举值，代码更简洁。
• 序列化后的 payload 更小，传输效率更高。
• 接口文档更清晰，每个API对应的参数结构一目了然。

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