是的，gRPC单连接下并发请求复用同一TCP连接，前提是客户端未主动关闭、服务端未强制断连、且所有请求指向相同target（含host:port和TLS配置）；底层由HTTP/2连接池管理，同一ClientConn内的UnaryCall或Stream共享连接并分配不同stream ID。
gRPC 单连接下并发请求真的复用同一个 TCP 连接吗？
是的，但前提是客户端没主动关闭、服务端没强制断连、且所有请求都发向同一 target（含相同 host:port 和相同 TLS 配置）。gRPC Go/Java/Python 客户端默认启用 HTTP/2 连接复用，底层由 http2.Transport 或等价机制管理连接池——单个 grpc.ClientConn 实例内部只维护一个或少数几个 TCP 连接，具体数量受 MaxConnsPerHost（Go）或 maxInboundMessageSize 等间接参数影响。
- 不同
ClientConn实例之间绝对不共享连接，哪怕 target 完全一致 - 同一
ClientConn发出的多个UnaryCall或Stream会复用同一个 HTTP/2 连接，走不同 stream ID - 若调用中发生
UNAVAILABLE错误且伴随connection reset by peer，大概率是连接被中间设备（如 LB、防火墙）中断，此时 gRPC 会新建连接，不是“复用失效”，而是“复用被迫重建”
压测时多 goroutine 共享一个 ClientConn 会遇到什么瓶颈？
瓶颈不在连接数，而在 HTTP/2 流控、序列化开销和客户端线程竞争。典型现象是：QPS 上不去、延迟毛刺增多、stream ID exhausted 报错（尤其在长连接 + 高频短请求场景）。
- HTTP/2 协议规定单连接最大流数为
2^31 - 1，但 gRPC 实现（如 Go 的grpc-go）默认限制为100并发流（可通过WithMaxConcurrentStreams调整） - 每个 stream 建立有固定开销：序列化 request、生成 stream ID、写入帧头；高并发下 protobuf 序列化可能成为 CPU 瓶颈
- 多 goroutine 同时调用
Invoke会竞争ClientConn内部的mu互斥锁（尤其在初始化 stream 时），Go client 在 v1.48+ 已优化该锁粒度，但旧版本仍明显 - 示例：若压测脚本用 1000 goroutine 循环调用
client.SayHello(ctx, req)，但未设置WithMaxConcurrentStreams(1000)，实际并发流会被卡在 100，其余请求排队等待
什么时候必须用多个 ClientConn？
当单连接无法满足吞吐、隔离性或故障域要求时，不是“为了并发而多连”。
- 跨地域调用：不同 region 的 endpoint 必须用独立
ClientConn，否则 DNS 解析或路由策略冲突 - 多租户场景：需按 tenant 切分连接，避免某租户突发流量拖垮其他租户的 stream 资源
- 故障隔离：某个
ClientConn因网络抖动频繁重连，不应影响其他业务通道；gRPC 不提供连接级熔断，只能靠多实例 + 外部健康检查实现 - 极高吞吐场景（>5w QPS）：单连接受内核 socket 缓冲区、网卡队列、HTTP/2 流控窗口限制，实测中常在 2~3w QPS 出现延迟陡增，此时横向扩展
ClientConn数量比调大单连接参数更有效
HTTP/2 stream 层面怎么确认是否真复用了？
别信文档，看 wire log 或 Go runtime 的 http2.FrameDebugWriter，重点观察 HEADERS 帧里的 stream ID 变化和 SETTINGS 是否重复协商。
- 启用 gRPC 日志：
GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info，搜索transport: loopyWriter.run和transport: http2Client.notifyError可看到 stream 创建/关闭轨迹 - 抓包过滤
http2.stream_id != 0 and tcp.port == 你的端口，连续请求应看到 stream ID 递增（1, 3, 5…），而非反复从 1 开始 - 注意：stream ID 是 client-initiated 的奇数 ID，server-initiated 是偶数，gRPC 只用奇数；若看到大量 ID 重置（如从 101 突然跳回 1），说明连接被重置过，不是“复用”，是“重建”
- 常见误判点：Wireshark 解析 HTTP/2 依赖 TLS 握手密钥，明文环境可直接看；TLS 环境需导出
SSLKEYLOGFILE才能解密帧内容
真实压测中，连接复用只是基础，真正卡点往往在 protobuf 编解码效率、服务端 handler 阻塞、或 HTTP/2 窗口自动调节滞后。别急着加连接数，先用 pprof 看 client 侧 CPU 和 goroutine 分布，再决定动哪一层。
