.proto中双向流必须在请求和响应类型前均加stream关键字，否则生成单向流导致调用失败；服务端方法签名固定，需从stream.context()获取上下文；客户端须用两个goroutine异步处理send/recv并监听done()。
proto 文件里必须同时写两个 stream 关键字
双向流不是配置开关，是 .proto 语法硬性要求：请求类型和响应类型前都得加 stream。漏一个就生成单向流接口，运行时根本调不通。
-
rpc Chat(stream Message) returns (stream Message)✅ 正确双向流 -
rpc Chat(Message) returns (stream Message)❌ 服务端流，客户端只能发一次 -
rpc Chat(stream Message) returns (Message)❌ 客户端流，服务端只能回一次
错误现象：生成的客户端方法签名是 ChatClient，但服务端接收参数却是 ChatServer 或 ChatClientStream——类型不匹配。编译能过，但调用永远卡在 Recv()，没有错误提示，调试极难定位。
服务端函数签名不能手动加 context.Context
生成的服务端方法签名是固定的，比如 func (s *server) Chat(stream pb.ChatService_ChatServer) error。你不能往里塞额外参数，也不能在函数体里直接用传入的 ctx 控制流生命周期。
- 正确做法：从
stream.Context()拿上下文，它已自动绑定连接生命周期 - 常见错误：自己调
context.WithTimeout包一层，导致超时后Recv()突然返回context.Canceled，但服务端逻辑没清理资源，连接可能卡在半关闭状态 -
Recv()返回io.EOF表示客户端调了CloseSend()，不是错误，要主动退出循环；返回其他err（如status.Error或网络断开）才该return err让 gRPC 清理
客户端必须用两个 goroutine 分别处理 Send 和 Recv
双向流不是“发一条等一条”，Send() 和 Recv() 必须完全异步。同一个 goroutine 里交替调用，极易因某次 Recv() 阻塞而卡死整个流，后续消息永远发不出去。
- 发数据的 goroutine 必须监听
stream.Context().Done()，一旦取消立刻停止Send()，否则可能 panic - 收数据的 goroutine 要持续
for { res, err := stream.Recv(); ... }，不能只调一次 - 初始化流时绝不能用
context.Background()，必须用context.WithCancel或context.WithTimeout，否则流 hang 住会永久泄漏 goroutine - 不要在
Send()后立刻调CloseSend()，除非确定客户端不会再发任何消息；否则服务端提前收到io.EOF，中断接收逻辑
流式通信中容易被忽略的清理点
最常被跳过的不是发送逻辑，而是资源释放路径：客户端没调 CloseSend()、服务端没检查 Recv() 的 io.EOF 就直接 return、goroutine 没监听 stream.Context().Done() 导致泄漏——这些不会立刻报错，但在高并发或长连接场景下会缓慢堆积内存和连接句柄。
尤其注意：服务端流（returns (stream T)）和客户端流（rpc X(stream T) returns (R)）的错误处理模式完全不同，混用双向流的惯性思维去写单向流，很容易漏掉关键退出条件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
