Protobuf中将编码消息存入bytes字段再编解码的正确性及风险问询

这套操作在严格遵循对应编码逻辑的前提下可以正常跑出预期结果，但是属于严重不规范的Protobuf使用反模式，存在大量隐性风险，非常不推荐生产环境使用。

• 丧失Protobuf原生的向前/向后兼容性能力：如果你后续对B结构体做符合Protobuf规范的迭代（比如按规则保留字段号新增字段、删除废弃字段），原生嵌套定义的场景下Protobuf框架会自动兼容新旧版本数据，但手动用bytes存储的场景下所有兼容逻辑都需要自己手动实现，稍有不慎就会出现解析失败、数据丢失的问题。
• 额外的性能开销：相比直接在A中嵌套B类型的写法，你需要多执行两次B的序列化、反序列化操作，会产生不必要的CPU开销；同时bytes字段的编码会额外占用几个字节的长度标识空间，数据体积也会略大于原生嵌套的写法。
• 可维护性大幅下降：从Protobuf定义中完全无法看出A的B字段存储的是B类型的序列化结果，后续维护人员很容易误用该字段，也无法直接使用Protobuf自带的反射工具、JSON转码工具、调试打印工具直接查看B的内容，排查问题的成本极高。
• 缺失类型安全校验：原生嵌套B的场景下Protobuf编译器会在编译期做类型校验，完全避免传入错误类型的问题，但用bytes存储时，如果你不小心把其他类型的序列化字节存入该字段，反序列化为B时只会出现无意义的乱码或者直接解析失败，框架无法提前发现问题。
• 提升跨语言适配成本：Protobuf原生对不同语言的类型、编码处理是完全对齐的，但是手动维护bytes字段的序列化反序列化时，很容易因为不同语言的字节处理逻辑差异出现兼容性问题。

直接将A的定义修改为嵌套B类型即可，不需要额外做手动的序列化反序列化，所有逻辑都由Protobuf框架自动处理：

message A {
  B B = 1;
}

message B {
   int32 c = 1;
   int64 d = 2;
   string x = 3;
}

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