双向流连接需主动维护：go 侧用 context 控制生命周期、显式判错、协程分离收发；服务端 recv() 遇 io.eof 应正常退出，其他错误才返回；禁用 time.sleep，须 select 判断上下文；客户端必须双 goroutine 分离 send/recv；proto 必须含两个 stream 关键字；服务端用生成的 server 类型，客户端用 client 类型；各流 context 独立，不可共享。
双向流连接不是“建完就稳”，不主动维护就会在 NAT 超时、服务重启或网络抖动后静默断开。Go 侧必须靠 context 控制生命周期 + 显式错误判断 + 协程分离收发，才能撑住长连接。
服务端 recv 循环里怎么正确处理 io.EOF 和真实错误
Recv() 返回 io.EOF 表示客户端调用了 CloseSend()，这是正常结束信号，不是异常，应主动退出循环并返回 nil；其他非 nil 错误（如 status.Error、transport is closing、context.Canceled）才该直接 return，让 gRPC 自动清理连接。
- 别把
io.EOF当错误log或panic，否则会掩盖真正的连接中断 - 服务端不要在循环里用
time.Sleep等待新消息——HTTP/2 流是事件驱动的，阻塞只会拖慢响应 - 每个
Recv()调用前建议加select判断stream.Context().Done()，防止上下文已取消还继续读
客户端为什么必须用两个 goroutine 分离 send/recv
单 goroutine 串行调用 Send() 和 Recv() 必然卡死：一旦某次 Recv() 阻塞（比如服务端没发新消息），后续 Send() 就永远发不出去。
- 发数据 goroutine：持续从本地
chan取消息 → 调用stream.Send()→ 每次前检查stream.Context().Err() == nil - 收数据 goroutine：
for { res, err := stream.Recv(); }，遇到io.EOF表示服务端关闭发送端，可退出；遇到其他err应通知上层是否重连 - 绝不能复用
context.Background()，长连接必须配context.WithCancel()或context.WithTimeout()
.proto 定义和生成代码必须严格匹配双向流语义
只要漏掉一个 stream 关键字，生成的 Go 接口就不是双向流——编译能过，运行时却不会被调用，客户端卡在等待响应。
- 正确写法：
rpc Chat(stream Message) returns (stream Message) - 错误写法：
rpc Chat(Message) returns (stream Message)（服务端流）、rpc Chat(stream Message) returns (Message)（客户端流） - 服务端方法签名禁止手动加
context.Context参数，必须用生成的pb.ChatService_ChatServer类型 - 客户端拿到的
stream是pb.ChatService_ChatClient，它只有Send()和CloseSend()，没有Recv()
最易被忽略的是服务端 handler 里共享 stream 上下文
服务端 handler 里不能共享全局状态来存 stream 上下文，每个流的 Context() 是独立的，混用会导致并发污染或超时失效。
长连接真正稳定的关键，不在“建得多快”，而在“错得清楚、退得干净”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
