本文详解 go 程序在高频、多域名 http 请求场景下因 http.Transport 连接复用机制导致的内存持续增长问题，指出 DisableKeepAlives: true 是关键修复手段，并提供可落地的优化代码与实践建议。
本文详解 go 程序在高频、多域名 http 请求场景下因 `http.transport` 连接复用机制导致的内存持续增长问题，指出 `disablekeepalives: true` 是关键修复手段，并提供可落地的优化代码与实践建议。
在使用 Go 编写爬虫、监控或批量页面采集工具时，开发者常遇到一个隐蔽但严重的性能问题：程序运行时间越长，内存占用越高，最终触发 OOM Killer 终止进程——即使已正确调用 resp.Body.Close()。问题并非出在响应体读取逻辑本身，而在于 Go 标准库 net/http 的底层连接管理机制。
Go 的 http.DefaultTransport 默认启用 HTTP/1.1 Keep-Alive，会为每个目标主机（host）维护空闲连接池（idle connection pool），以便后续请求复用 TCP 连接，提升性能。然而，当程序访问成千上万个不同域名（如从日志或爬取队列中动态加载 URL）时，Transport 会为每个新 host 缓存一个空闲连接（含 bufio.Reader/Writer 等缓冲区），导致内存持续累积且无法自动释放。pprof 输出中 bufio.NewReaderSize 和 net/http.(*Transport).getIdleConnCh 占比高，正是这一现象的典型特征。
根本解法是禁用连接复用，避免 Transport 为海量不同 host 缓存连接。只需自定义 http.Transport 并设置 DisableKeepAlives: true，再将其注入 http.Client：
func worker(linkChan chan string, wg *sync.WaitGroup) { defer wg.Done() // 关键：禁用 Keep-Alive，防止为每个新 host 缓存连接 transport := &http.Transport{ DisableKeepAlives: true, // 可选：进一步限制资源占用（适用于极端规模） MaxIdleConns: 0, MaxIdleConnsPerHost: 0, IdleConnTimeout: 0, } client := &http.Client{Transport: transport} for url := range linkChan { resp, err := client.Get(url) if err != nil { fmt.Printf("Fail url: %sn", url) continue } // 必须读取并关闭 Body，否则连接可能无法及时释放（即使 DisableKeepAlives） body, err := io.ReadAll(resp.Body) resp.Body.Close() // 始终在读取后立即关闭 if err != nil { fmt.Printf("Fail reading url: %sn", url) continue } hasRemCode := strings.Contains(string(body), "googleadservices.com/pagead/conversion.js") fmt.Printf("Done url: %st%tn", url, hasRemCode) } }✅ 注意事项：
- DisableKeepAlives: true 是核心修复项；额外设置 MaxIdleConns=0 等参数可强化效果，但非必需。
- resp.Body.Close() 仍需保留——它不仅释放连接，还确保底层 io.ReadCloser 资源（如缓冲区）被回收。
- 避免使用已废弃的 ioutil.ReadAll（Go 1.16+），应改用 io.ReadAll（需导入 “io”）。
- 若业务允许，可考虑对同一 host 复用 Client 实例（而非每次新建 Transport），但本场景因 host 极度分散，禁用 Keep-Alive 更直接有效。
总结：Go 的 HTTP 内存泄漏常源于 Transport 的“善意缓存”。面对海量异构域名请求，应主动放弃连接复用，以空间换稳定性。该方案零侵入、低开销，是生产环境批量 HTTP 调用的必备实践。