gRPC 连接泄露不是“连接没关”，而是 grpc.ClientConn 实例被创建后长期持有、未调用 Close()，或被意外逃逸到长生命周期作用域（比如全局变量、单例容器），导致底层 TCP 连接、HTTP/2 stream 管理器、缓冲区池、定时器等资源持续驻留——内存和 goroutine 都会缓慢上涨。
如何确认是 ClientConn 泄露而非其他问题
线上出现内存/协程缓慢增长 + /debug/pprof/goroutine?debug=2 显示大量 http2.(*ClientConn).readLoop 或 transport.loopyWriter 协程，且数量随请求量线性上升，基本可锁定为 ClientConn 未关闭。注意：这不是 goroutine 泄露本身，而是未关闭连接触发的底层协程保活。
- 用
go tool pprof http://$IP:$PORT/debug/pprof/goroutine进入交互后执行top，若看到数百上千个http2.(*ClientConn).readLoop占比超 90%，就是强信号 - 检查代码中所有
grpc.Dial调用点，确认是否每个都配对了defer conn.Close()，尤其注意 error 分支是否遗漏 - 警惕“复用连接”逻辑：如果把
*grpc.ClientConn存在 map、sync.Pool 或全局变量里，但没做连接健康检查或过期淘汰，也会造成事实上的泄露
grpc.Dial 的 WithBlock 和 WithTimeout 不解决泄露，反而加重风险
这两个选项只影响 Dial 阶段的行为，和连接生命周期管理完全无关。滥用 WithBlock 会导致初始化卡死；WithTimeout 超时后返回 error，但若忽略 error 继续用 nil conn，运行时 panic；更糟的是，有人误以为设置了 timeout 就“自动回收”，结果 conn 一直悬着。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
WithBlock：阻塞等待连接建立成功，不推荐用于服务启动阶段（可能拖慢就绪探针） -
WithTimeout：仅作用于 DNS 解析 + TCP 握手 + TLS 握手 + HTTP/2 Preface，不是连接池空闲超时 - 真正控制连接生命周期的是你何时调用
conn.Close()，不是 dial 参数
连接池最大连接数？gRPC-Go 本身没有“连接池”概念，只有 ClientConn 复用
gRPC-Go 不提供类似数据库连接池的 MaxOpenConns 配置。每个 *grpc.ClientConn 内部维护一个 HTTP/2 连接（可复用多路 stream），它默认支持并发 stream，不需要也不应该为每次 RPC 新建 conn。所谓“最大连接数”，其实是你代码里创建了多少个未关闭的 ClientConn 实例。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：全局或 per-service 复用一个
*grpc.ClientConn，通过context.WithTimeout控制单次 RPC 超时 - 错误做法：在 handler 里写
conn, _ := grpc.Dial(...); defer conn.Close()—— 每次请求新建连接又立即关，TCP 握手开销大，且Close()是异步清理，高频创建+关闭反而引发transport层 goroutine 泄露 - 若需隔离（如多租户、不同 TLS 配置），应按需创建 conn 并显式管理其生命周期，用
sync.Once或依赖注入框架确保单例，而不是靠“限制数量”来掩盖泄露
最常被忽略的一点：ClientConn 关闭后，所有基于它的 ClientStream（尤其是 streaming 场景）必须已结束，否则 Close() 会阻塞等待，甚至触发 context deadline 被 cancel 导致不可预期行为。stream 的收发循环里，一定要用 select 监听 ctx.Done() 和 stream.Recv()，不能只靠 io.EOF 判断退出。
