gRPC消息中未指定类型的data字段如何存储JSON类型数据

方案1：使用bytes类型存储序列化后的JSON数据 #

这个是改造成本最低的方案，直接修改你的proto定义中data字段的类型即可：

// 方案1不需要导入额外依赖
message ResponseMessage {
    bool success = 1;
    string message = 2;
    uint32 status_code = 3;
    bytes data = 4; // 方案1：用bytes类型存储序列化后的JSON二进制
    repeated string error = 5;
}

• 使用逻辑：业务侧将需要返回的object对象序列化为JSON二进制流存入data字段，接收方拿到响应后直接对data字段做JSON反序列化即可得到原始数据。
• 优点：完全适配任意结构的JSON数据，不需要调整proto定义就能兼容所有数据库查询返回结构，传输效率高。
• 缺点：需要自行实现JSON和二进制流的序列化/反序列化逻辑，gRPC原生调试工具无法直接查看data字段的内容。

方案2：使用protobuf官方内置的google.protobuf.Struct类型 #

这个是官方推荐的用来承载任意JSON结构的类型，不需要自行处理序列化逻辑：

// 方案2需要导入官方依赖包
import "google/protobuf/struct.proto";

message ResponseMessage {
    bool success = 1;
    string message = 2;
    uint32 status_code = 3;
    google.protobuf.Struct data = 4; // 方案2：用官方内置Struct类型承载JSON结构
    repeated string error = 5;
}

• 使用逻辑：主流编程语言的gRPC SDK都已经内置了Struct和原生字典/JSON对象的互转方法，直接调用对应API就能完成赋值和读取，不需要手动做JSON序列化。
• 优点：不需要自行处理序列化逻辑，开发效率高，gRPC调试工具可以直接识别Struct结构并展示为JSON格式，方便调试。
• 缺点：传输效率略低于bytes方案，序列化后的体积比bytes大10%~20%左右。

选型建议 #

如果你的接口是通用数据库查询接口，返回结构完全不固定，优先选方案2，开发效率更高；如果对传输性能要求极高，或者需要传输超大体积的JSON数据，优先选方案1。如果后续你的接口返回的data结构可枚举，也可以用oneof语法定义所有可能的返回结构体类型，类型安全性更高，但不适合结构完全不固定的通用查询场景。

内容的提问来源于stack exchange，提问作者سعید خیری