gRPC流式连接断开后Recv()不会panic，真正panic的是未检查错误就继续调用Recv()或在已关闭stream上调用Send()；必须新建stream而非重用，且需用backoff.Retry实现带jitter的指数退避重连。
gRPC流式连接断开后 Recv() 直接 panic：为什么不能只靠重试
Go 客户端调用 stream.Recv() 时，如果底层 TCP 连接已断开但 stream 尚未被显式关闭，Recv() 会立即返回 io.EOF 或 status.Error(codes.Unavailable, ...)，**不会 panic**；真正 panic 的往往是后续继续调用 Recv() 而没检查错误，或在已关闭的 stream 上误调 Send()。关键在于：gRPC stream 是单向生命周期，一旦出错就不可恢复，必须新建 stream。
常见错误现象：
- 循环中无条件 stream.Recv(&msg)，没包 if err != nil 判断
- 捕获到 io.EOF 后仍尝试 stream.Send()，触发 panic: send on closed channel
- 把重连逻辑写在 for 循环内部，但没重置 stream 变量，导致复用已关闭对象
- 每次重连都必须调用新
client.StreamMethod()获取全新 stream 实例 -
Recv()和Send()都需独立判错，不能假设一方成功另一方也一定可用 - 不要依赖
context.DeadlineExceeded判断网络断开——它只反映本地超时，不等于对端失联
用 backoff.Retry + grpc.WithBlock() 实现可控重连
直接用 time.Sleep() 硬等是反模式：阻塞 goroutine、无法响应取消、不支持 jitter。推荐用 github.com/cenkalti/backoff/v4 库，它原生支持指数退避 + jitter + context 取消。
注意：grpc.Dial() 默认异步建连，client.StreamMethod() 可能返回 “connection refused” 类错误，不是 stream 层问题。必须确保底层连接可用，否则重连 stream 毫无意义。
- Dial 时加
grpc.WithBlock()（仅调试/关键路径），让Dial()阻塞直到连通或超时，避免后续 stream 创建失败 - 重试函数体里先
client.NewStream()，再Send()（如有）、Recv()循环，整个流程包在backoff.Retry()中 - 退避配置示例：
backoff.WithMaxRetries(backoff.NewExponentialBackOff(), 5)，默认 base=500ms，max=1min，含随机 jitter
bo := backoff.NewExponentialBackOff()
bo.MaxElapsedTime = 30 * time.Second
err := backoff.Retry(func() error {
stream, err := client.MyStreamingRPC(ctx)
if err != nil {
return err // 连接失败，重试
}
// 启动 recv 循环...
return nil
}, bo)
流式重连时如何不丢消息、不重复消费
gRPC 本身不保证流式消息的 exactly-once 语义。断线重连是否丢数据，取决于服务端是否支持断点续传（如通过 last_seen_id 或 cursor 参数）。客户端能做的只有：最小化重连窗口 + 显式传递上下文。
立即学习“go语言免费学习笔记（深入）”；
典型场景：订阅日志流、实时行情、IoT 设备事件。这类场景下，服务端通常要求客户端带上上次收到的序列号或时间戳。
- 在重连前记录最后成功处理的
msg.Id或msg.Timestamp - 新建 stream 时，把该值作为
Request字段传入（例如req.ResumeFromId = lastId） - 避免在
Recv()循环内做耗时操作（如 DB 写入），否则重连间隔拉长，增加重复风险 - 服务端若不支持 resume，客户端只能接受“至少一次”语义，并自行去重（如用
map[uint64]struct{}缓存近期 ID）
Context 取消和超时必须贯穿全程
一个被遗忘的 context 会让重连 goroutine 泄漏，尤其当 backoff.MaxElapsedTime 很大或网络长期不可达时。所有环节都要响应 cancel。
错误做法：用全局 context.Background() 调 stream.Recv()，或重试函数里忽略传入的 ctx。
- 每个
client.StreamMethod()都传入带 timeout 或 cancel 的ctx -
backoff.Retry()第二个参数支持backoff.Context，必须传入父 context - 在
Recv()循环中定期 selectctx.Done()，及时退出
最易被忽略的是：重连间隔本身也要受 context 约束。backoff.ExponentialBackOff 的 NextBackOff() 返回 -1 表示停止重试，但它不感知 context —— 必须手动 wrap。
