连接复用的性能收益必须量化：本机回环下新建连接耗时是复用的42.8倍，跨机房更达百倍以上；需实测net.Dial耗时、监控连接池命中率（低于80%则收益有限）、观察TIME_WAIT锐减及tcpdump验证SYN包减少。
连接复用的性能收益不是靠“感觉”或“配置开关”判断的，而是必须量化三次握手开销与连接池命中率。在本机回环场景下，新建连接耗时是复用连接的 42.8 倍；跨机房环境下这个差距会进一步放大到百倍以上。
测出真实连接建立耗时（net.Dial 的开销）
直接测量 net.Dial 的耗时，才能锚定复用带来的绝对收益。别只看整体 RTT，要单独剥离连接阶段：
- 用
time.Now()包裹net.Dial调用，排除后续读写干扰 - 确保测试目标服务已就绪（避免 DNS 解析、服务启动延迟混入）
- 至少采集 1000 次样本，取 P95 或中位数，而非平均值（网络抖动影响大）
- 对比两组数据：一组每次调用都
net.Dial，另一组复用同一个net.Conn多次Write/Read
示例关键片段：
for i := 0; i < 1000; i++ {
start := time.Now()
conn, err := net.Dial("tcp", "127.0.0.1:8080")
dialDur := time.Since(start)
if err != nil {
continue
}
conn.Close()
// 记录 dialDur
}
区分“连接复用”和“连接池命中率”两个指标
很多人误把“用了连接池”等同于“复用生效”，其实关键要看命中率。连接池空闲连接被回收、超时、主动关闭都会导致 miss：
立即学习“go语言免费学习笔记（深入）”；
-
http.Transport类型池：监控IdleConnStats字段，重点关注IdleConnTimeout是否过短、MaxIdleConnsPerHost是否不足 - 自定义 TCP 连接池（如基于
sync.Pool）：在Get和Put路径埋点，统计hit/miss比例 - miss 高的典型原因：请求间隔 >
IdleConnTimeout、连接被远程主动断开（RST）、池大小设为 0 或 1
命中率低于 80%，复用带来的收益就非常有限，此时优化方向应是调大池子或延长保活时间，而不是换序列化库。
观察 TIME_WAIT 状态数量变化
这是最容易被忽略但最硬的证据。复用连接后，单位时间内新建连接数下降，系统 TCP_TW 状态数应同步锐减：
- Linux 下执行：
ss -s | grep "TCP:"或netstat -s | grep -i "time wait" - 对比开启复用前后的每秒新增
TIMED-WAIT数（可用watch -n1动态观察） - 若数值未明显下降，说明连接并未真正复用——可能每次都在
Close()后又立刻Dial()，或连接被中间设备（如 NAT 网关）强制中断
注意：net.ipv4.tcp_tw_reuse = 1 只是让内核能重用 TIME_WAIT 端口，并不等于应用层实现了连接复用，两者不能混淆。
抓包确认 SYN 包是否真的变少了
最终验证手段：用 tcpdump 抓客户端出口流量，过滤 SYN 包计数：
- 命令：
tcpdump -i any -c 1000 'tcp[tcpflags] & tcp-syn != 0 and dst port 8080' -w syn.pcap - 运行相同业务逻辑 30 秒，分别在启用/禁用连接复用时各抓一次
- 用
wireshark打开比对 SYN 包总数，或用tshark -r syn.pcap | wc -l
如果复用开启后 SYN 包数量没降，那一定是代码里还在频繁调用 net.Dial，或者连接被异常关闭后没有被池子回收（比如 panic 导致 defer 未执行）。这种问题光看日志和指标很难定位，必须落到包层面。
真正卡住性能的往往不是“要不要复用”，而是“为什么复用没生效”——连接池大小、超时设置、错误路径下的连接泄漏、甚至 defer conn.Close() 被提前触发，都可能导致你白配了参数却看不到效果。
