CloseIdleConnections仅清理空闲连接，无法解决连接泄漏；泄漏主因是未读取resp.Body或响应体读取不完整，导致连接被卡住。
CloseIdleConnections 为什么不能解决连接泄漏
调用 CloseIdleConnections 并不会关闭正在使用的连接，它只清理 http.Transport 内部空闲连接池中处于 idle 状态的连接。如果你看到连接数持续上涨、netstat 显示大量 ESTABLISHED 或 TIME_WAIT，大概率是请求没完成就丢了引用，或者响应体没读完导致连接被卡住——这时候调 CloseIdleConnections 没用。
常见诱因包括：
- 忘记读取
resp.Body，比如直接defer resp.Body.Close()却在读取前就 return - 使用
io.Copy(ioutil.Discard, resp.Body)但没检查返回错误，底层 read 失败后连接未被标记为可复用 - 自定义
http.Transport时设置了过大的MaxIdleConnsPerHost，但业务 QPS 很低，连接长期 idle 却不释放
什么时候该主动调用 CloseIdleConnections
它适合用在「连接池需要被明确重置」的场景，比如服务热重启、配置变更后重建 http.Client、或测试中避免端口耗尽。不是每次请求后都要调，更不该放在 HTTP handler 里频繁执行——这会把本可复用的连接强行断开，反而增加 TLS 握手和 TCP 建连开销。
典型安全用法：
- 进程退出前：在
os.Interrupt信号处理中调用一次 - 客户端生命周期结束时：比如一个短期任务型 client（如 CLI 工具），执行完所有请求后调用
- 单元测试 teardown 阶段：防止多个 test case 复用同一 Transport 导致状态污染
示例：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConnsPerHost: 20,
},
}
// ... 发起若干请求
client.CloseIdleConnections() // 清理残留 idle 连接，仅此一次
真正控制长连接生命周期的关键参数
CloseIdleConnections 是“事后清理”，真正影响连接是否复用、复用多久的，是 http.Transport 的几个超时字段。漏配或乱配会导致连接堆积或过早断连。
必须关注的三项：
-
IdleConnTimeout：空闲连接保留在池中的最长时间，默认 30s。设太长（如 5m）会让 idle 连接滞留太久；设太短（如 1s）则复用率骤降 -
TLSHandshakeTimeout：TLS 握手最长等待时间，超时后连接被丢弃。若后端 TLS 响应慢，这里要适当放宽 -
ResponseHeaderTimeout：从写完 request 到读到 response header 的最大等待时间。不设可能导致连接卡在 header 阶段，既不失败也不复用
注意：Timeout（总超时）不控制连接复用逻辑，它只作用于单次请求上下文，不影响 Transport 内部连接状态。
调试连接状态的实用方法
光看代码很难确认连接是否真被复用或泄漏，得靠运行时观察：
- 启用 Transport 日志：设置
http.Transport.ForceAttemptHTTP2 = false+ 抓包，或用curl -v对比 - 统计连接数：通过
net/http/pprof的/debug/pprof/goroutine?debug=1查看是否有大量阻塞在readLoop的 goroutine - 导出指标：给 Transport 打补丁，在
getConn和putIdleConn中埋点，记录当前 idle 连接数变化
一个容易被忽略的细节：CloseIdleConnections 是同步阻塞调用，内部会逐个关闭 idle 连接，如果池中有几百个连接，它可能卡住几十毫秒——别在高并发 handler 中触发它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
