grpc go 客户端默认启用连接级自动重连，但仅对unavailable、resource_exhausted等特定错误触发，且退避参数若未显式配置则沿用basedelay=1s、maxdelay=120s等保守默认值，易导致恢复延迟过长或同步重连风暴。
gRPC Go 客户端默认重连机制是否够用
够用，但必须确认它真在工作——gRPC Go 默认启用连接级自动重连，但它只对 UNAVAILABLE、RESOURCE_EXHAUSTED 等特定错误码触发，且退避参数若没显式配置，会沿用保守的默认值（BaseDelay=1s，MaxDelay=120s）。你看到“连不上”或“卡几十秒才恢复”，大概率不是没重连，而是退避太慢或状态卡在 TRANSIENT_FAILURE 没退出。
为什么服务重启后客户端迟迟不重连
常见原因是连接状态机卡住，而不是重连机制失效。gRPC 连接有五种状态：Idle、Connecting、Ready、TransientFailure、Shutdown。服务端重启时，客户端可能长期停留在 TransientFailure，并按指数退避等待下一次尝试，期间不会响应新 RPC 请求。
- 调用
conn.ResetConnectBackoff()强制清空当前退避计时器 - 紧接着调用
conn.EnterIdle()让连接回到Idle状态 - 任一后续 RPC 调用会立即触发新连接流程，绕过原退避延迟
- 可在捕获到
status.Code(err) == codes.Unavailable时自动触发这两步
流式 RPC 断线后 Recv() 不 panic，但继续调用会 panic
stream.Recv() 在底层断开时返回 io.EOF 或 status.Error(codes.Unavailable, ...)，**它本身不会 panic**；真正 panic 的是：在已关闭的 stream 上继续调用 Recv() 或 Send()，尤其是未检查错误就无条件循环 stream.Recv(&msg)。
- 每次循环必须先判
err != nil，io.EOF和codes.Unavailable都需退出当前 stream 循环 - 退出后必须新建 stream：调用
client.MyStreamingRPC(ctx)获取全新实例，不能复用旧stream变量 - 不要在
Recv()出错后还调用stream.Send()—— channel 已关闭，直接 panic - 重连逻辑必须包裹整个流程：新建 stream → Send（如有）→ Recv 循环，全部放在
backoff.Retry()中
如何配置 Backoff.Config 避免重试翻车
填错 Backoff.Config 是最隐蔽的性能坑：设太激进（BaseDelay ）会引发重试风暴；设太保守（<code>MaxDelay > 120s）会让用户感知超长不可用；漏掉 Jitter 会导致所有客户端同步重连，瞬间压垮服务端。
-
BaseDelay建议从1s起手，别低于500ms -
Multiplier推荐1.6～2.0，1.6更适合多数服务恢复节奏 -
MaxDelay别超过120s，否则重连失去业务意义 - 显式设置
Jitter: 0.2，否则手动 new 的 config 默认Jitter = 0 - 不要依赖
context.DeadlineExceeded判断断连——它只反映本地超时，不等于对端失联
真正难的是把连接可用性、stream 生命周期、错误分类和退避节奏串成一条可靠链路，而不是堆参数或写重试循环。每一步断在哪，都得有对应的状态反馈和清理动作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
