在Golang的gRPC流式通信中，必须通过context.Context处理异常。应监听上下文取消或超时，及时释放资源，设置合理超时，避免连接长时间挂起，并在goroutine中通过context控制生命周期。
在使用 Golang 和 gRPC 实现流式通信时，异常处理是确保服务健壮性的关键部分。gRPC 支持四种类型的流：单向请求、服务器流、客户端流和双向流。无论哪种流式模式，连接一旦建立，错误可能在任意时刻发生，因此必须合理捕获和处理异常。
流式上下文取消与超时
流式调用依赖于 context.Context，任何上下文的取消或超时都会中断流。服务端或客户端应监听上下文状态，及时释放资源。
建议：- 始终检查
ctx.Err()判断上下文是否已关闭 - 设置合理的超时时间，避免长时间挂起连接
- 在 goroutine 中处理流时，确保能通过 context 控制生命周期
示例代码：
for {
select {
case <-ctx.Done():
log.Println("stream context canceled:", ctx.Err())
return ctx.Err()
default:
req, err := stream.Recv()
if err != nil {
// 进入统一错误处理
break
}
// 处理请求
}
}
接收与发送中的错误判断
在调用 Recv() 或 Send() 时，返回的 error 是判断流状态的主要依据。常见的错误包括网络中断、对端关闭、序列化失败等。
立即学习“go语言免费学习笔记（深入）”；
关键点：
-
io.EOF表示流正常结束，通常出现在服务器流或双向流中，客户端停止发送 - 非
nil错误需结合status.Code(err)判断具体原因 - 使用 google.golang.org/grpc/status 包解析错误码
示例处理逻辑：
req, err := stream.Recv()
if err != nil {
if statusErr, ok := status.FromError(err); ok {
switch statusErr.Code() {
case codes.Canceled:
log.Println("client canceled the stream")
case codes.DeadlineExceeded:
log.Println("stream deadline exceeded")
default:
log.Printf("stream error: %v", statusErr.Message())
}
} else {
log.Printf("network or serialization error: %v", err)
}
return err
}
服务端流写入失败处理
服务端在调用 Send() 时，若客户端已断开，会返回错误。不能假设每次发送都成功。
- 每次
Send()后必须检查 error - 遇到错误后应立即退出循环，避免持续写入无效流
- 可记录日志，但不应 panic
典型写法：
for item := range dataChan {
if err := stream.Send(item); err != nil {
log.Printf("failed to send item: %v", err)
return err // 结束当前流处理
}
}
客户端主动关闭与资源清理
无论是客户端还是服务端，在流异常终止时，应确保：
- 关闭相关资源（如数据库连接、文件句柄）
- 通知其他协程停止工作
- 记录必要的错误日志以便排查
可在 defer 中执行清理：
defer func() {
// 清理逻辑
cancel() // 如果有 context.WithCancel
close(someChannel)
}()
基本上就这些。流式异常处理不复杂，但容易忽略细节。关键是始终检查 error，正确解析状态，并及时释放资源。
