服务端流是客户端单请求、服务端多响应的grpc通信模式，适用于实时推送、日志拉取等“单推多收”场景；定义需在.proto中声明rpc getmetrics(metricsrequest) returns (stream metricsresponse)；服务端实现须多次调用stream.send()并避免复用同一实例；客户端须循环recv()并正确处理io.EOF。
gRPC服务端流模式的定义和适用场景
服务端流（Server Streaming）是指客户端发一个请求，服务端返回多个响应消息的通信模式。它适合实时推送、日志拉取、监控指标持续上报这类“单推多收”场景，不是用来替代http长轮询或websocket的，别一上来就想着做聊天室。
- 客户端调用一次
GetUpdates()，服务端通过同一个stream.Send()发送多次数据 - 每次发送都走同一个HTTP/2流，底层复用连接，没有频繁建连开销
- 客户端必须用循环读取
stream.Recv()，直到返回io.EOF - 不支持服务端中途“取消”某次发送——流的生命周期由客户端关闭或服务端返回错误决定
定义.proto文件时的关键写法
服务端流的语义完全靠 .proto 文件里的 stream 关键字声明，gRPC工具链据此生成对应接口。漏掉 stream 或放错位置，生成的代码就不是流式接口。
- 返回类型前加
stream，请求类型保持普通（单个消息）：rpc GetMetrics (MetricsRequest) returns (stream MetricsResponse) {} - 别写成
rpc GetMetrics (stream MetricsRequest) returns (stream MetricsResponse)——那是双向流，不是服务端流 -
MetricsResponse必须是 message 类型，不能是 primitive（如String或int32） - 如果你用的是 proto3，记得显式加
syntax = "proto3";，否则 protoc 可能静默降级为 proto2 并报奇怪的生成错误
服务端实现里最容易卡住的三个点
生成代码后，服务端要实现的函数签名形如 func (<em>server) GetMetrics(req </em>pb.MetricsRequest, stream pb.YourService_GetMetricsServer) Error。这个 stream 参数不是 channel，也不是 callback，是带状态的 gRPC 流对象。
- 必须在函数返回前调用
stream.Send()多次，每次传入新构造的*pb.MetricsResponse实例；重复用同一个实例并改字段会导致数据被覆盖（因为 proto 序列化复用内部 buffer） - 每次
Send()后不要立即time.Sleep()等待——gRPC 本身不保证发送时机，但阻塞会拖慢整个流；真要节流，用time.Ticker控制发送节奏 - 如果在循环中遇到错误（比如 DB 查询失败），应先调用
stream.Send()发送最后一条错误附带消息（可选），再 return 错误；直接 return 会让客户端收到rpc error: code = Unknown desc = ...，但不会触发Recv()的io.EOF
客户端接收流时的典型崩溃原因
客户端拿到的 stream 是 YourService_GetMetricsClient 类型，它的 Recv() 方法是阻塞的。很多新手在这里写出死锁或 panic。
立即学习“go语言免费学习笔记（深入）”；
- 循环必须以
for { resp, err := stream.Recv(); if err != nil { break } }结构开始，不能漏掉err == io.EOF的判断——它代表服务端正常结束流，不是异常 - 不要在
Recv()外层套select等待超时却忘了处理io.EOF，否则超时逻辑可能永远不触发 - 如果服务端长时间不发数据，
Recv()会一直挂起，直到连接被 Keepalive 探活机制断开（默认 2 小时），想提前感知断连得自己加 context.WithTimeout 并传给 RPC 调用 - 别在
Recv()循环里启动 goroutine 处理resp却不加同步控制——多个 goroutine 并发读同一个resp字段会引发 data race（Go 的 proto Struct 是值类型，但内部有指针字段）
服务端流看着简单，但流的状态管理、错误传播、资源释放都在暗处咬人。最常出问题的不是逻辑，而是忘记检查 err 是否为 io.EOF，或者把 stream.Send() 当成普通函数随意复用变量。