HTTP连接泄漏表现为QPS低但lsof -i :443数量激增、dial timeout或connection reset日志频发，且netstat显示ESTABLISHED/TIME_WAIT持续累积，pprof可见大量goroutine卡在http.Transport.roundTrip。
Go 程序出现 socket: too many open files 或连接数持续上涨，基本可以断定是网络连接没释放干净——不是“用了太多连接”，而是该关的没关，连接卡在 idle 状态或半关闭状态，长期占用文件描述符。
怎么确认是 HTTP 连接泄漏，而不是数据库或别的问题？
HTTP 连接泄漏最典型的外在表现是：QPS 不高（比如每秒 5–10 次请求），但 lsof -i :443 | wc -l 结果却从 20 涨到 200+ 并不回落；同时日志里反复出现 dial tcp: i/o timeout 或 read tcp: connection reset by peer。这和数据库连接泄漏不同：sql.DB.Stats().OpenConnections 上涨对应的是 database/sql 层的连接池，而 HTTP 连接泄漏直接反映在系统级 fd 数量上，且常伴随 http.Transport 相关阻塞堆栈。
- 用
netstat -an | grep ':443' | grep -E '(ESTABLISHED|TIME_WAIT)' | wc -l对比压测前后变化，若 ESTABLISHED 持续累积、TIME_WAIT 堆积不退，就是连接没归还 - 访问
http://localhost:6060/debug/pprof/goroutine?debug=2，搜索http.(*Transport).roundTrip或net/http/transport.go，看是否有大量 goroutine 卡在select或chan receive—— 这说明底层连接正在等待复用或超时清理 - 别只看
runtime.NumGoroutine()：协程数可能只涨几十，但每个卡住的 goroutine 背后都钉着一个 TCP 连接和对应的 fd
为什么 defer resp.Body.Close() 在循环里会失效？
因为 defer 是函数退出时才执行，不是每次迭代结束就调用。如果把 defer resp.Body.Close() 写在 for 循环外部，那只有最后一次请求的 resp.Body 会被关；前 N−1 次的响应体全悬着，连接永远进不了 idle pool。
- 错误写法：
for i := 0; i < 10; i++ { resp, err := http.Get(url) if err != nil { continue } defer resp.Body.Close() // ❌ 只会关最后一次 // ... 处理 resp } - 正确写法：要么把逻辑拆成独立函数（让 defer 生效），要么显式调用：
for i := 0; i < 10; i++ { resp, err := http.Get(url) if err != nil { continue } // ✅ 立即关，不依赖 defer resp.Body.Close() // ... 处理 resp } - 更安全的模式：需要读取 body 时再用 defer，且确保它在当前作用域内：
for i := 0; i < 10; i++ { func() { resp, err := http.Get(url) if err != nil { return } defer resp.Body.Close() // ✅ 此时 defer 绑定到匿名函数作用域 io.ReadAll(resp.Body) // 或其他读取操作 }() }
http.Client 和 Transport 配置不当如何放大泄漏？
默认的 http.DefaultClient 看似省事，但它共享全局 http.DefaultTransport；一旦某处代码修改了它的 MaxIdleConns，所有用默认 client 的地方都会被拖累。而未配置的 http.Transport 在高并发下极易堆积空闲连接却不释放。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式配置 Transport，并设合理值：
var httpClient = &http.Client{ Timeout: 30 * time.Second, Transport: &http.Transport{ MaxIdleConns: 500, MaxIdleConnsPerHost: 500, IdleConnTimeout: 30 * time.Second, TLSHandshakeTimeout: 10 * time.Second, }, } -
IdleConnTimeout设太长（如 5 分钟）会导致连接挂太久；设太短（如 2 秒）又会让复用失效，频繁建连——30 秒是较稳妥的平衡点 - 切忌在 handler 里每次 new
&http.Client{}：每个 client 实例自带独立 transport，不复用、不共享连接池，等于手动制造泄漏源 - 注意
req.Close = true是反模式：它禁用 keep-alive，强制服务器断连，客户端侧反而无法复用连接，导致新建更多连接却仍不释放
真正难排查的不是“完全没关”，而是“关晚了”——比如在异步回调里延迟关闭、在 channel 关闭后还继续读、或者 context 超时后没及时中断读取。这些场景下连接不会立刻报错，但会在后台缓慢堆积，直到 fd 耗尽才暴露。盯住 lsof + pprof/goroutine + http.Transport 配置三者联动，比单看日志或内存更直接有效。
