grpc连接天然支持复用，无需手动实现连接池；应全局持有*grpc.clientconn实例，避免频繁dial/close，并正确配置认证、keepalive等参数以确保长连接稳定。
gRPC 连接本身就能复用，不用手动实现“连接池”
Go 的 grpc.ClientConn 天然支持并发复用和长连接管理，官方明确不推荐、也不提供类似 sql.DB 那样的连接池抽象。所谓“gRPC 连接池”，其实是误用概念——你真正要做的，是正确创建和持有 *grpc.ClientConn 实例，并避免频繁 grpc.Dial / conn.Close()。
什么时候该复用 *grpc.ClientConn？
只要服务端地址不变、认证/拦截器等配置一致，同一 *grpc.ClientConn 就可被多个 goroutine 安全复用，且底层 TCP 连接会自动保活、重连、负载均衡（配合 round_robin 等 resolver）。
- 单个微服务内部调用：全局或包级变量持有一个
*grpc.ClientConn即可 - 多租户场景（不同 token 或 TLS 证书）：每个租户配一个独立
*grpc.ClientConn，不要混用凭证 - 短命任务（如 CLI 工具一次执行）：仍建议复用，但需控制
WithTimeout和WithBlock行为，避免阻塞
grpc.Dial 的关键参数别设错
建连行为几乎全由 grpc.Dial 参数决定；设错会导致看似“复用了”，实则每次调用都在新建底层连接。
- 漏掉
grpc.WithTransportCredentials(insecure.NewCredentials())（开发时）或credentials.NewTLS(...)（生产）→ 报错connection error: desc = "transport: authentication handshake failed" - 没加
grpc.WithBlock()且未处理context.DeadlineExceeded→Dial立即返回nilconn，后续调用 panic - 误用
grpc.WithInsecure()（已弃用）→ 编译失败，必须换为insecure.NewCredentials() - 忘记
grpc.WithKeepaliveParams(...)→ 网络空闲时连接被中间设备（NAT、LB）静默断开，下次调用触发重连延迟
关闭时机比创建更关键
conn.Close() 是昂贵操作，且不可逆；过早关、重复关、漏关都会出问题。
- 在 HTTP handler 或 RPC 方法里每次调用都
defer conn.Close()→ 连接被立刻释放，下次调用又得重建 - 进程退出前没调
conn.Close()→ 可能残留 TIME_WAIT 连接，但通常无害；真要优雅关，用ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second); defer cancel(); conn.Close() - 多个模块共用一个
conn，但各自Close()→ 第二次Close()无效果，但可能掩盖资源泄漏意图
最稳妥的做法：把 *grpc.ClientConn 当作常驻资源，在应用初始化时创建，生命周期与进程一致；只在程序退出前关一次。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
