关于gRPC-Go服务端流式处理方法无context参数的疑问

1. 为何常规Unary RPC处理器带context.Context，而服务端流式RPC处理器没有？ #

gRPC-Go 中，Unary RPC（单次请求-响应）的生命周期是一次性的：客户端发请求、服务端处理并返回响应，整个过程的上下文（调用元数据、超时/取消信号等）直接绑定到这单次调用上，所以框架会把context.Context作为参数直接传入处理器方法。

而服务端流式RPC的调用是持续的：客户端发一次请求，服务端多次返回响应，整个流的生命周期贯穿多次响应的发送过程。gRPC-Go 把这个持续调用的上下文封装在了ServerStream接口里，所以处理器方法不需要单独传入context.Context，直接通过ServerStream实例就能获取到贯穿整个流的上下文。

2. 是否应该使用server.Context()获取上下文？ #

是的，这是官方推荐的正确方式。对于服务端流式RPC，你需要通过ServerStream.Context()方法来获取当前调用的上下文，它能提供你需要的所有调用级别的上下文信息（比如元数据、取消信号、超时设置等）。

3. ServerStream.Context()返回的上下文与Unary RPC传入的上下文是否一致？ #

完全一致。不管是Unary RPC传入的context.Context，还是服务端流式RPC通过ServerStream.Context()获取的上下文，都是同一个调用级别的上下文实例，包含相同的调用元数据、取消/超时信号、传递的值等。比如当客户端发起调用取消时，这两个上下文都会被触发取消，你可以通过<-ctx.Done()来监听这个信号。

举个简单的代码示例对比：

• Unary RPC处理器：

func (s *myServer) UnaryCall(ctx context.Context, req *pb.MyRequest) (*pb.MyResponse, error) {
    // 直接使用传入的ctx
    md, ok := metadata.FromIncomingContext(ctx)
    // ...处理逻辑
}

• 服务端流式RPC处理器：

func (s *myServer) StreamCall(req *pb.MyRequest, stream pb.MyService_StreamCallServer) error {
    // 通过stream获取上下文
    ctx := stream.Context()
    md, ok := metadata.FromIncomingContext(ctx)
    // ...流式响应逻辑
}

这两段代码里的ctx是同一个实例，功能完全等价。

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