Go 的 net/http 默认复用 TCP 连接，但需客户端与服务端协同支持 keep-alive，且中间代理（如 Nginx）不主动关闭连接；关键配置在 http.Transport 的 MaxIdleConns、MaxIdleConnsPerHost 和 IdleConnTimeout 等参数。
Go 的 net/http 默认不复用 TCP 连接？其实是复用的，但得配对
Go 标准库的 http.Client 默认启用连接复用，但前提是服务端也支持 Connection: keep-alive 且未主动关闭。很多人看到 tcpdump 里频繁出现 SYN，其实是没配对好：客户端开了复用，服务端却每响应完就 close，或者中间有代理（如 Nginx）默认禁用了长连接。
关键配置在 http.Transport：
-
MaxIdleConns：整个 client 能保持的最大空闲连接数（默认 100） -
MaxIdleConnsPerHost：每个 host（如 api.example.com）最多缓存多少空闲连接（默认 100） -
IdleConnTimeout：空闲连接保活多久后关闭（默认 30s） -
TLSHandshakeTimeout和ResponseHeaderTimeout也要设，否则超时会中断复用链路
示例：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 60 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
},
}
自己手写 TCP 连接池？通常没必要，除非你绕过 HTTP
如果用的是裸 net.Conn（比如对接 Redis、MySQL 协议、自定义二进制协议），才需要自己管连接池。标准库没有现成的通用 TCP 池，得靠 sync.Pool 或第三方包（如 github.com/jolestar/go-commons-pool），但要注意：连接不是无状态对象，不能随便 Put 回去。
常见错误现象：write: broken pipe、use of closed network connection，往往是因为把已断开或超时的连接塞回池子，下次 Get 出来直接 panic。
立即学习“go语言免费学习笔记（深入）”；
- 每次
Get后必须做健康检查（例如发个PING或SELECT 1） -
Put前必须确认连接还可用（conn.RemoteAddr() != nil不够，得conn.SetReadDeadline尝试读点东西） - 池子大小要结合并发量和后端承受力调，盲目设大反而压垮服务端
http.Transport 的 DialContext 可以接管底层 TCP 建连逻辑
如果你真要控制 TCP 层行为（比如加 SO_KEEPALIVE、绑定特定网卡、走自定义 DNS 解析），别改 http.Client 外层，而是定制 Transport.DialContext。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
它返回一个 net.Conn，你可以在这里做：
- 设置
SetKeepAlive和SetKeepAlivePeriod - 用
net.Dialer.Control注入setsockopt（如SO_REUSEPORT） - 记录建连耗时、失败原因，用于监控
注意：DialContext 本身不能阻塞太久，否则拖慢整个连接池调度；失败时要返回具体错误（如 &net.OpError{Op: "dial", Net: "tcp", Err: xxx}），否则 http.Transport 无法正确重试或降级。
连接池失效的隐蔽原因：DNS 缓存、TLS 会话复用、HTTP/2
即使所有参数都设对了，连接池也可能“看起来没生效”。三个高频盲区：
- DNS 解析结果被缓存，但 IP 变了（比如 K8s Service 后端 Pod 重建），旧连接还在用老 IP，新请求却打到新 IP —— 实际上开了两套池子
- TLS 会话复用（Session Resumption）失败时，
http.Transport会新建连接而不是复用，但日志里不报错，只能看tls.HandshakeComplete统计 - HTTP/2 默认强制多路复用，
MaxIdleConnsPerHost对它基本无效；但若服务端只支持 HTTP/1.1，客户端又启用了 HTTP/2，可能因 ALPN 协商失败退回到短连接
查证方式：开启 GODEBUG=http2debug=2 看协商日志；用 lsof -iTCP -n -p $PID 数真实 ESTABLISHED 连接数，比代码里设的阈值更可信。
连接池不是设了参数就自动变聪明的东西，它依赖两端协议配合、网络中间件放行、以及你愿意花时间验证每条链路是否真的复用了。
