Unary是单次请求-响应模式，适合常规RPC场景；Stream分Client/Server/BiDi三类，复用TCP连接实现多次消息交互；选型应基于数据交互需求而非性能或“高级”程度。
Unary 是单次请求-响应，适合常规 RPC 场景
当你调用一个 gRPC 方法，客户端发一次请求、服务端回一次响应，中间不保持连接，这就是 Unary。它和 HTTP 的 GET/POST 语义最接近，也是默认生成的 stub 类型。
常见错误是误以为 Unary 能“推”数据：比如想让服务端在响应后持续发新消息——这做不到，Unary 的 ctx 在响应返回后就结束，服务端无法再写入。
实操建议：
- 用
proto定义时，方法签名形如rpc GetUserInfo(UserID) returns (User)，即单入单出 - 服务端 handler 函数签名必须是
func(ctx context.Context, req *XXXRequest) (*XXXResponse, error) - 超时、鉴权、日志等中间件天然适配，因为生命周期清晰
Stream 分为 Client/Server/BiDi 三类，核心是复用 TCP 连接传递多条消息
Stream 不是“流式传输大文件”的代名词，而是指在同一个 gRPC 调用上下文中，允许多次读写。区别在于谁主动发起消息：
立即学习“go语言免费学习笔记（深入）”；
-
ClientStreaming：客户端发多条，服务端收完再统一响应（如日志批量上报） -
ServerStreaming：客户端发一次，服务端边处理边发多条响应（如实时行情推送） -
BidiStreaming：双方可随时读写，类似聊天室（如协作文档同步）
容易踩的坑是忽略流的关闭时机：Send() 后不调 CloseSend()，服务端会一直等；或客户端未循环 Recv() 就退出，导致部分响应丢失。
示例（ServerStreaming）：
func (s *server) ListEvents(req *pb.ListRequest, stream pb.EventService_ListEventsServer) error {
for _, e := range s.events {
if err := stream.Send(&pb.Event{Id: e.ID, Data: e.Payload}); err != nil {
return err
}
time.Sleep(100 * time.Millisecond)
}
return nil
}Unary 和 Stream 的底层 transport 差异影响连接复用与错误恢复
gRPC 底层基于 HTTP/2，Unary 每次调用对应一个 HTTP/2 DATA 帧往返；而 Stream 复用同一个 HTTP/2 stream ID，所有消息共享连接状态。
这意味着：
- Stream 更省连接数，但单个 stream 故障（如网络抖动）会导致整个流中断，需应用层重连或重试逻辑
- Unary 天然幂等（GET 类），而 ServerStreaming 无法保证“断点续传”，除非你在 proto 中显式带 offset 或 cursor 字段
- 拦截器（interceptor）对 Stream 的
stream参数需要特殊处理——不能像 Unary 那样直接 wrapctx，得包装xxxServer接口
选型关键看数据交互模式，不是性能或“高大上”程度
别因为 Stream 听起来更“高级”就强行用 BiDi。真实项目中 80% 的场景用 Unary 更稳：调试方便、超时控制明确、可观测性工具（如 grpcurl）支持完整。
真正该切 Stream 的信号只有两个：
- 需要服务端主动推送（非轮询），且客户端必须实时接收（如告警通知）→ 选
ServerStreaming - 客户端要连续上传并等待服务端渐进反馈（如语音识别分片上传+实时文字返回）→ 选
BidiStreaming
其他情况，先写 Unary，压测发现瓶颈再评估是否值得改。
