gRPC服务稳定性取决于连接复用、分层超时、条件重试与拦截器边界治理：全局复用*grpc.ClientConn避免频繁拨号；context超时+服务端Keepalive/MaxConnectionAge协同控制；仅对Unavailable等临时错误限次指数重试；拦截器聚焦轻量日志与认证，熔断限流交由专用组件。
gRPC 服务在 Go 中跑得稳不稳，不取决于你写了多少接口，而在于连接怎么管、超时怎么设、错误怎么兜、重试怎么控。治理不是加一堆中间件就完事，是每个环节都得有明确意图和边界。
复用 grpc.ClientConn 实例，别每次调用都 grpc.Dial
频繁创建 grpc.ClientConn 是最常见性能黑洞：TCP 握手、TLS 协商、HTTP/2 连接初始化全得重来，尤其在高并发下延迟飙升、FD 耗尽。
-
ClientConn本身线程安全，支持并发Invoke和NewStream，一个实例可被整个服务复用 - 别在 handler 或业务方法里写
grpc.Dial(...)，统一在init()或依赖注入阶段创建并缓存 - 配合
WithBlock()要谨慎：它会让Dial阻塞直到连接 ready，线上 DNS 解析慢或后端未就绪时会卡死启动 - 记得调用
conn.Close()在应用退出时释放资源，否则可能残留连接和 goroutine
超时必须分层设置：context.WithTimeout + grpc.WaitForReady + 服务端 grpc.MaxConnectionAge
单靠客户端 context 超时不保险，服务端没响应、连接卡住、流挂起都会绕过它。
- 客户端发起调用前，用
context.WithTimeout(ctx, 5*time.Second)控制单次 RPC 生命周期 - 对非关键路径调用，可加
grpc.WaitForReady(false)避免阻塞；对强一致性场景（如扣库存），设为true并配更长超时 - 服务端务必配置
grpc.KeepaliveParams和grpc.MaxConnectionAge，防止长连接僵死、内存泄漏或连接数失控 - 注意：
grpc.Timeout这类过时选项已弃用，只认 context 超时
重试要带条件，不能无脑 WithRetry
gRPC 默认不重试，开了 grpc.WithRetry 后若不加约束，可能把幂等性破坏、放大下游压力、甚至触发雪崩。
立即学习“go语言免费学习笔记（深入）”；
- 只对可重试错误重试：
codes.Unavailable、codes.DeadlineExceeded、codes.ResourceExhausted，绝不能重试codes.AlreadyExists或codes.InvalidArgument - 必须设置最大重试次数（建议 ≤ 3）和指数退避（
grpc.RetryBackoff），避免瞬间重压 - 业务关键接口（如支付、转账）应由服务端自己处理幂等，而不是依赖客户端重试——重试只是网络层容错，不是业务逻辑兜底
- 开启重试后，务必关闭
grpc.WaitForReady，否则重试逻辑与等待逻辑会冲突
拦截器里做治理，但别塞太多逻辑
UnaryServerInterceptor 和 UnaryClientInterceptor 是治理落地最自然的位置，但容易变成“万能钩子”，反而拖慢所有请求。
- 日志拦截器只打必要字段：method、code、latency、peer，避免序列化大 request/response body
- 监控指标（如 Prometheus counter/gauge）更新必须轻量，用
atomic或预分配 labels，别在拦截器里做 DB 查询或 HTTP 调用 - 认证/鉴权拦截器应早失败：验证失败立即 return error，别往下走再拦
- 不要在拦截器里做重试、熔断、限流——这些该由独立组件（如
google.golang.org/grpc/balancer或外部 service mesh）承担
真正难的不是加功能，是判断哪个环节该由 gRPC 自身承担，哪个该交给注册中心、sidecar 或业务代码。比如服务发现走 resolver.Builder，熔断用 hystrix-go 封装 client，而 token 校验必须进 interceptor —— 边界划不清，治理就只剩堆砌。
