如何在Go-gRPC的Protobuf消息中正确包含错误字段？

首先明确：Protobuf本身不支持直接用error作为字段类型——这是因为Protobuf的字段类型仅支持固定基础类型或自定义消息类型，error是Go的内置接口，不属于Protobuf的类型系统范畴。

下面是几种比单纯存储错误字符串更规范、可控的实现方式：

1. 自定义结构化错误消息 #

定义专门的ErrorDetail消息，包含错误码、描述、附加元数据等字段，让错误信息结构化，方便下游服务解析处理：

message ErrorDetail {
  int32 code = 1; // 可映射gRPC标准错误码，比如grpc.Code()返回的数值
  string message = 2; // 错误描述文本
  map<string, string> metadata = 3; // 附加上下文信息，如请求ID、链路追踪ID等
}

message ProxiedMessage {
  bytes wrappedRpc = 1;
  ErrorDetail err = 2; // 用自定义错误消息替代字符串字段
}

在Go代码中转换后端返回的错误：

import "google.golang.org/grpc/status"
import "google.golang.org/grpc/codes"

// 处理后端返回的err
st, ok := status.FromError(err)
if ok {
    proxiedMsg.Err = &ErrorDetail{
        Code:    int32(st.Code()),
        Message: st.Message(),
        Metadata: map[string]string{
            "request_id": reqID,
            // 按需添加其他元数据
        },
    }
} else {
    // 处理非gRPC标准错误
    proxiedMsg.Err = &ErrorDetail{
        Code:    int32(codes.Unknown),
        Message: fmt.Sprintf("Unknown error: %v", err),
    }
}

这种方式的优势是错误信息结构化，下游可以根据错误码做逻辑判断，而非解析模糊的字符串，可靠性和扩展性更强。

2. 复用gRPC标准错误消息 #

gRPC本身提供了标准的status.Status对应的Protobuf定义（google/rpc/status.proto），可以直接复用该类型，无需自定义错误结构：
首先在proto文件中导入标准定义：

import "google/rpc/status.proto";

message ProxiedMessage {
  bytes wrappedRpc = 1;
  google.rpc.Status err = 2;
}

Go代码中转换错误的逻辑更简洁：

import "google.golang.org/grpc/status"
import "google.golang.org/grpc/codes"

// 处理后端返回的err
st, ok := status.FromError(err)
if !ok {
    st = status.New(codes.Unknown, fmt.Sprintf("Unknown error: %v", err))
}
proxiedMsg.Err = st.Proto()

这种方式完全遵循gRPC的错误标准，和现有gRPC生态兼容，下游如果是gRPC服务，可直接将Status转回error使用，无需额外适配。

3. 保留字符串但约定格式（简易方案） #

如果不想引入额外消息类型，也可以继续用字符串字段，但约定统一的可解析格式（比如JSON），让错误信息具备结构化能力：

import "encoding/json"

// 定义错误信息结构体
type errorInfo struct {
    Code    int32  `json:"code"`
    Message string `json:"message"`
}

// 序列化错误为JSON字符串
info := errorInfo{
    Code:    int32(codes.Unknown),
    Message: err.Error(),
}
jsonStr, _ := json.Marshal(info)
proxiedMsg.Err = string(jsonStr)

下游可将字符串反序列化为结构体获取结构化信息，但这种方式可靠性低于前两种，字符串解析过程容易出现格式兼容问题。

总结来说，最推荐复用gRPC标准Status消息的方式，既符合规范又能兼容现有gRPC生态；如果需要自定义元数据，自定义错误结构的方式更灵活。单纯使用无格式字符串虽然可行，但不利于后续的错误处理和系统扩展。

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