应结合 grpc.WaitForReady(true) 或 health.Check RPC 判断连接可用性，而非仅依赖 State()；避免 WithBlock() 卡死，改用非阻塞 Dial + 异步健康检查；ClientConn 复用需引用计数或空闲超时管理，并每次取用前校验状态。
如何用 grpc.ClientConn.State() 判断连接是否真的可用
调用 State() 只能告诉你当前状态枚举值，比如 CONNECTING 或 READY，但不保证下一次 RPC 就成功——它不触发真实网络探测，只是本地状态快照。
真正要确认连通性，得配合 grpc.WaitForReady(true) 或主动发一个轻量级健康检查 RPC（如 health.Check）。否则你看到 READY 却在后续调用里收到 rpc error: code = Unavailable，很常见。
- 别只依赖
State() == connectivity.Ready做业务路由或熔断决策 - 如果服务端刚重启、TLS 握手未完成，
State()可能卡在CONNECTING很久，需设超时重试 - 状态变更监听要用
cc.WaitForStateChange(ctx, lastState)，不是轮询State()
为什么 grpc.WithBlock() 在连接池初始化时容易卡死
WithBlock() 会让 grpc.Dial() 阻塞直到连接就绪或超时，但它依赖底层 DNS 解析 + TCP 连接 + TLS 握手 + HTTP/2 Preface 全部完成。任意一环慢（比如 DNS 超时 5s、服务端 TLS 证书校验慢），整个 Dial 就卡住，拖垮你的连接池启动逻辑。
生产环境几乎不用它。应该用非阻塞 Dial + 后续异步等待健康状态。
立即学习“go语言免费学习笔记（深入）”；
- 用
grpc.WithReturnConnectionError()替代，让Dial()快速返回，错误留在第一次 RPC 时暴露 - 连接池初始化后，用独立 goroutine 调用
cc.GetState() == connectivity.Ready+health.Check做最终确认 - 注意：gRPC 默认重试策略对
UNAVAILABLE是指数退避，首次失败不等于永久不可用
怎么安全地复用 *grpc.ClientConn 并监控其生命周期
一个 *grpc.ClientConn 天然支持并发 RPC 调用，也支持多 service client 复用，但它的关闭是全局的——cc.Close() 会终止所有正在跑的流和待发请求。
所以连接池管理不能靠“每个请求 new 一个 conn”，也不能“用完立刻 Close”，而要基于引用计数或连接空闲超时来回收。
- 用
sync.Pool缓存*grpc.ClientConn时，New函数必须做健康检查，避免吐出已断开的 conn - 每次从池取 conn 后，先调用
cc.GetState()，如果是ShuttingDown或TransientFailure，直接丢弃并新建 - 不要在 HTTP handler 里直接调
cc.Close()；应由连接池统一管理，用time.AfterFunc()触发空闲连接清理
grpc_health_v1.HealthClient 的正确调用姿势和坑点
标准健康检查服务不是“开了就行”，客户端调用它本身也可能失败：DNS 解析失败、连接未就绪、服务端没注册 health service、或响应超时。
关键是要把 health check 当作一次真实 RPC 来处理，而不是“探针”。它走的是同一条 gRPC 通道，共享连接状态和拦截器。
- 务必设置
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)，避免 hang 住 - 不要忽略
err：如果Check(ctx, &req)返回非 nil err，且是codes.Unavailable或codes.DeadlineExceeded，说明连接层已不可用 - 服务端启用 health 检查需显式注册：
health.RegisterHealthServer(grpcServer, health.NewServer())，漏掉这句，客户端永远收不到响应
连接池健康度不是静态值，它随网络抖动、服务端扩缩容、证书轮换实时变化。最危险的误判，就是把一次成功的 State() 或 Check() 当成长期承诺。
