gRPC流式通信由.proto文件中stream关键字位置决定：服务端流为rpc Foo(Req) returns (stream Res)，客户端流为rpc Foo(stream Req) returns (Res)，双向流为rpc Foo(stream Req) returns (stream Res)；错误写法、message未显式定义、Send/Recv使用不当等均会导致运行时阻塞或数据错乱。
gRPC 流式通信不是“开启某个开关”，而是由 .proto 文件里 stream 关键字决定的——写错位置、漏写、或生成命令少一个插件，后面所有代码都跑不起来。
proto 文件里怎么写 stream 才算对
服务端流、客户端流、双向流，全靠 stream 出现在请求/响应类型前的位置区分。它不是修饰符，是语法组成部分，不能省略也不能放错。
-
rpc GetLogs(LogRequest) returns (stream LogResponse)→ 服务端流（客户端发一次，服务端回多次） -
rpc Upload(stream Chunk) returns (UploadResult)→ 客户端流（客户端发多次，服务端回一次） -
rpc Chat(stream Message) returns (stream Message)→ 双向流（双方都能随时收发） - 别写成
rpc Bad(stream LogRequest) returns (LogResponse)：这既不是标准客户端流（少stream在返回），也不符合 gRPC 接口契约，生成代码会缺失关键方法 - message 必须显式定义，不能用
string或bytes直接当参数；repeated bytes data是高危写法，容易触发 OOM，应改用单次bytes data+int64 offset分块设计
服务端实现时最常卡死的三个地方
函数签名看着简单，但实际运行中很容易在某次 Send() 就永久阻塞——不是代码逻辑错，而是没处理好流的生命周期和底层传输行为。
-
Send()是同步写入 HTTP/2 流的，不加错误检查就循环调用，一旦客户端断开或网络卡住，goroutine 就 hang 住，表现为 CPU 低但连接数持续上涨 - 服务端函数必须返回
error类型，且只能有一个stream参数（在请求参数之后），不能额外加context.Context参数——要用stream.Context() - 别复用同一个 message 实例反复改字段再
Send()：proto 序列化内部 buffer 会被覆盖，客户端收到的可能是上一轮的数据 - 需要节流时，用
time.Ticker控制节奏，而不是在Send()后直接time.Sleep()，后者会拖慢整个流的响应窗口
客户端读 ServerStream 的正确姿势
很多人以为能像读 channel 一样 for range client，但 client.Recv() 不是迭代器，它每次只取一个消息，必须手动循环调用，否则只读第一条就退出。
立即学习“go语言免费学习笔记（深入）”；
- 标准写法就是：
for { res, err := stream.Recv(); if err != nil { break }; handle(res) } -
err == io.EOF表示服务端正常结束流；err != nil && err != io.EOF才是异常中断（比如连接断开、服务崩溃） - 别在
Recv()前做重 IO 操作（如查 DB），否则一次失败就丢掉后续所有消息；建议先启动 goroutine 拿数据，主循环专注收流 - 如果客户端要主动取消，调用
stream.CloseSend()（仅对客户端流/双向流有效），服务端会收到io.EOF；服务端无法“中途取消”某次发送，流的关闭权在客户端或错误传播路径上
双向流里 goroutine 怎么配才不漏消息
双向流要求收发并行，但若把 Recv() 和 Send() 放进同一个 for 循环，一旦某次 Recv() 阻塞，Send() 就永远等不到机会——必须拆到独立 goroutine。
- 客户端必须开一个 goroutine 专跑
Recv()循环，主流程或另一个 goroutine 负责Send() - 服务端同理：一个 goroutine 处理
Recv()，另一个（或同一 goroutine 内用select）负责Send()，否则容易出现“发不出去”或“收不回来” - 别依赖
for range stream.Recv()，它根本不存在；也别用stream.RecvMsg()而不配合select+ 超时，否则网络抖动时协程会假死 - 双方都要检查
stream.Context().Err()，尤其在长连接场景下，超时、取消、Keepalive 失败都会通过这个 context 通知
流式通信真正的复杂点不在语法，而在对 HTTP/2 流控、TCP 连接状态、buffer 堆积和上下文取消的敏感度——这些细节不会报编译错误，但会让服务在线上静默失联或内存缓慢泄漏。
