使用gRPC时服务端与客户端之间应当如何处理部分返回结果？

核心思路是拆分封装返回内容的结构，同时兼顾存量客户端的兼容逻辑和完整信息传递需求，以下是按适用优先级排序的可落地方案：

方案1：扩展响应体新增元数据字段（最推荐，兼容所有存量逻辑） #

• 不需要改动原有结果字段的结构，只需要在返回体顶层新增元数据区块即可，Go语言示例结构如下（其他开发语言逻辑同理）：

type QueryResponse struct {
    Data     map[string]interface{} `json:"data"` // 原有结果存储字段，全量/部分结果都存在此处
    Metadata struct {
        IsPartial   bool   `json:"is_partial"` // 布尔标记位，明确标识本次返回是否为部分结果
        FailureCause string `json:"failure_cause,omitempty"` // 未完成全量查询的原因，全量返回时该字段为空
    } `json:"metadata"`
}

• 服务端处理逻辑：
  • 全量查询成功时，IsPartial设为false，FailureCause留空，返回nil错误
  • DB超时返回部分缓存结果时，IsPartial设为true，FailureCause填err.ConnDeadlineExceeded，依然返回nil错误
• 优势：
  • 存量客户端err == nil才读取结果的逻辑完全不需要修改，不会产生任何兼容问题
  • 有感知部分结果需求的客户端，可以主动读取metadata字段判断状态，按需决定是直接使用部分结果，还是单独重试查询未返回的条目

方案2：自定义特殊错误类型（适合内部服务调用场景） #

如果你的服务仅对内提供、所有调用方的代码逻辑可以统一升级的话，可以用自定义错误类型挂载部分结果：

type PartialResultError struct {
    PartialData map[string]interface{}
    Cause       error
}

func (e *PartialResultError) Error() string {
    return fmt.Sprintf("partial result returned, cause: %v", e.Cause)
}

• 服务端处理逻辑：DB超时时返回nil常规数据，同时返回&PartialResultError{PartialData: 缓存结果, Cause: err.ConnDeadlineExceeded}
• 客户端处理逻辑：可以通过类型断言判断错误是否为PartialResultError，如果是则读取内部挂载的PartialData使用，否则按普通错误处理
• 劣势：需要所有客户端升级错误判断逻辑，存量未升级的客户端会把这种情况当成普通错误处理，无法读取到部分结果，仅适合调用方完全可控的内部场景

方案3：HTTP状态码+响应体组合（HTTP接口场景补充优化） #

如果是对外提供HTTP接口，可以搭配状态码进一步降低识别成本：

• 全量返回时用标准的200 OK状态码
• 部分结果返回时用206 Partial Content状态码，响应体还是用方案1的带元数据的结构，网关、客户端可以直接通过状态码快速识别是部分结果，不需要先解析响应体

注意：无论选择哪种方案，都需要在接口文档中明确标注部分结果的返回规则、字段含义，避免客户端误用数据。

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