最直接验证连接复用的方法是观察tcp连接状态：稳定qps下netstat -an | grep :443 | grep established | wc -l结果不再线性增长；配合http trace监听gotconn.reused为true，以及监控/net/http/transport/idle_conns_idle与requests_served_total比值，可量化复用率。
Go 的 http.Client 默认就复用连接，但“默认启用”不等于“自动高效”——连接复用是否真在起作用、复用率有多高、卡点在哪，得靠可观测手段验证，不能凭感觉。
怎么看连接是否真的被复用了？
最直接的方式是观察 TCP 连接状态和 Transport 内部指标：
- 用
netstat -an | grep :443 | grep ESTABLISHED | wc -l（Linux/macOS）对比压测前后连接数变化：稳定 QPS 下连接数不再线性增长，说明复用生效 - 检查
http.Transport的IdleConnTimeout是否远大于请求间隔；若设成 5s，而请求每 2s 一次，连接大概率刚缓存就过期，复用率归零 - 开启 Go 的 HTTP trace（
httptrace.ClientTrace），监听GotConn和PutIdleConn事件：如果GotConn.Reused字段频繁为true，说明复用成功
为什么压测时连接数还在涨？常见配置陷阱
连接没复用，往往不是代码逻辑问题，而是 Transport 参数互相打架：
-
MaxIdleConnsPerHost设太小（比如还是默认的 2）：单个下游服务（如api.pay.example.com:443）最多只留 2 个空闲连接，60 QPS 下必然不断新建连接 -
MaxIdleConns总数不够：当同时调用 20+ 不同域名时，若MaxIdleConns还是 100，前几个 host 就把池子占满，其余请求只能新建连接 -
IdleConnTimeout设太短（如 10s）或太长（如 5m）：前者让连接活不过一次冷启动间隙；后者导致已断开的连接滞留池中，后续Do()会返回read: connection reset by peer
怎么量化复用率？用 runtime/metrics + 自定义统计
Go 1.20+ 提供了 runtime/metrics，可读取 Transport 内部计数器：
- 监控
/net/http/transport/idle_conns_idle（当前空闲连接数）和/net/http/transport/requests_served_total（总请求数）比值，越接近 1 表示复用越充分 - 手动加埋点：在
RoundTrip前后记录transport.IdleConnTimeout和实际耗时，统计“复用连接占比”和“平均复用次数” - 注意：这些指标只对同一个
*http.Transport实例有效；多个 client 共享 transport 才能聚合数据，否则每个 client 的池子彼此隔离
HTTP/2 场景下复用分析要额外看啥？
HTTP/2 复用的是单 TCP 连接上的多个 stream，但 Transport 层的连接池逻辑不变——只是连接粒度更粗：
- 确认协商成功：用
openssl s_client -alpn h2 -connect host:port看 ALPN 协商结果是否为h2 - 检查
MaxConcurrentStreams（默认 100）：若并发 stream 超限，客户端会收到RST_STREAM，表现为随机失败，不是连接复用问题，而是流控瓶颈 - 不要指望看到大量 ESTABLISHED 连接：一个 h2 连接撑几百 QPS 很正常；此时重点看单连接上的
stream创建/关闭速率，而非连接数
真正难调的从来不是参数值本身，而是不同参数之间的耦合关系——比如 MaxIdleConnsPerHost 和后端 Pod 数、LB 轮询策略、TLS 握手耗时都有关联；改一个值，得同步评估它对 DNS 缓存、连接保活、故障恢复的影响。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
