gRPC双向流服务端需实现持续读写stream的函数，用for循环调用Recv()并正确处理io.EOF和错误，Send()无需额外协程；客户端须启两个goroutine分别收发，避免串行卡死。
gRPC双向流在Go里怎么写服务端逻辑
服务端必须实现一个函数，接收 stream 参数并持续读写——不是一次返回，而是边收边发。很多人卡在这儿，以为要手动启协程管理连接，其实 gRPC 框架已经帮你把生命周期兜住了。
常见错误现象：context canceled 或流突然中断，往往是没正确处理 Recv() 的 EOF 和错误分支，导致循环提前退出或 panic。
- 必须用
for循环调用Recv()，每次检查返回的err：如果是io.EOF，说明客户端关闭了发送；其他非nil错误（比如网络断开）要主动return -
Send()不会自动 flush，但 gRPC 底层已做缓冲和流控，无需额外加锁或协程；但若发送频率高、消息小，可考虑批量合并再发，减少帧开销 - 每个
stream是独立上下文，别在 handler 里共享全局变量存状态——容易被并发流污染；要用stream自带的Context()做超时或取消控制
客户端如何发起并维持双向流连接
调用 ClientConn 上的方法拿到 stream 后，立刻启动两个 goroutine：一个发，一个收。这是唯一靠谱的模式，单线程串行读写必然卡死。
使用场景：实时日志推送、协作编辑、IoT 设备指令同步——这些都需要低延迟双向响应，不能靠轮询或单向流凑合。
立即学习“go语言免费学习笔记（深入）”；
- 发数据的 goroutine 要监听
ctx.Done()，避免往已关闭的 stream 写入引发 panic；Send()失败时别重试，直接退出 goroutine - 收数据的 goroutine 同样要检查
Recv()的err：遇到io.EOF表示服务端结束发送；status.Error类错误（如CANCELLED）需按业务逻辑判断是否重连 - 不要在
Send()后立刻Recv()——这不是请求响应模型；两边完全异步，靠业务协议（比如带 message ID）对齐语义
Proto 文件里定义 Bidirectional Stream 的关键点
必须用 stream 关键字同时修饰请求和响应类型，缺一不可。写成 rpc Chat(stream Message) returns (stream Message) 才算双向；写成单边 stream 就是客户端流或服务端流，不是双向。
参数差异：生成的 Go 接口里，服务端方法签名是 func(*MyService_ChatServer) error，客户端得到的是 *MyService_ChatClient，二者类型不同、方法不同，不能混用。
- message 字段尽量精简，避免嵌套深或含大二进制字段；双向流长期存活，内存泄漏风险比短连接高得多
- 不建议在 proto 里定义多个双向流 RPC 放同一个 service 下——Go 生成代码会共用一套 stream interface，但实际运行时每个 RPC 是隔离的；容易误以为能复用逻辑，结果 context 或 cancel 串了
- 如果需要携带元数据（如 auth token），必须在
context里传，proto message 里别硬塞；gRPC 的metadata.MD是独立通道，比塞 payload 更安全高效
调试双向流时最常踩的三个坑
本地跑通不代表线上可用。网络抖动、代理、TLS 配置都会让流静默失败，而错误码往往藏得很深。
性能影响：默认 HTTP/2 流量不压缩，大消息频繁收发会吃满带宽；兼容性上，gRPC-Web 不支持原生双向流，必须走 Envoy 等网关转接。
- 用
grpc.WithBlock()+grpc.WithTimeout()初始化 client conn，否则Dial可能立即返回未就绪的连接，后续Chat()直接 panic - 服务端 log 里看不到客户端断连？加
grpc.StreamInterceptor拦截CloseSend()和Recv()结束事件，不然只靠defer捕获不到流真正关闭时机 - Wireshark 抓不到 gRPC 包？因为 HTTP/2 是二进制帧，得用
grpclog开INFO级日志，或者用grpcurl -plaintext -v模拟调用看底层帧交互
双向流的本质是长生命周期的 socket 管理，框架只负责序列化和传输，状态同步、重连策略、消息去重都得自己补全。别指望一个 stream.Send() 调用就解决实时性问题。
