本文详解 Go 中 http.Get 导致内存泄漏的真实原因——并非 resp.Body.Close() 失效，而是默认 http.Transport 为复用连接而缓存大量空闲连接（尤其在高频访问不同域名时），并提供安全、可控的内存优化方案。
本文详解 go 中 `http.get` 导致内存泄漏的真实原因——并非 `resp.body.close()` 失效，而是默认 `http.transport` 为复用连接而缓存大量空闲连接（尤其在高频访问不同域名时），并提供安全、可控的内存优化方案。
在 Go 网络爬虫或大规模 URL 批量探测类程序中，开发者常误以为只要调用 resp.Body.Close() 就能彻底释放 HTTP 响应内存。但实际运行中，程序内存占用却随请求数线性攀升，最终触发 OOM Killer —— 这正是本文要解决的核心问题。
根本原因在于：Go 的默认 http.DefaultTransport 启用了连接复用（Keep-Alive），它会将每个成功响应后的底层 TCP 连接放入空闲连接池（idle connection pool），等待后续相同 Host 的请求复用。当程序高频访问成千上万个不同域名（如爬取海量独立站点）时，transport 会为每个新 Host 缓存至少一个空闲连接（含缓冲区、TLS 状态、读写器等），导致内存持续累积且无法被 GC 回收。
这与 ioutil.ReadAll 或 body 字符串本身无关（它们确实可被 GC），真正“吃掉”内存的是 net/http.(*Transport) 内部维护的 idleConn 映射表及关联的 bufio.Reader/Writer 实例（pprof 输出中 bufio.NewReaderSize 和 net/http.(*Transport).getIdleConnCh 占比最高，正是此现象的直接证据）。
✅ 正确解决方案：显式配置 http.Transport，禁用 Keep-Alive 并合理控制连接行为。以下是优化后的 worker 函数实现：
func worker(linkChan chan string, wg *sync.WaitGroup) {
defer wg.Done()
// 自定义 Transport：禁用 Keep-Alive，避免跨域名连接积压
transport := &http.Transport{
DisableKeepAlives: true, // 关键：彻底禁用连接复用
// 可选增强项（按需启用）：
// MaxIdleConns: 0, // 全局最大空闲连接数（设为 0 与 DisableKeepAlives 效果一致）
// MaxIdleConnsPerHost: 0, // 每 Host 最大空闲连接数（同上）
// IdleConnTimeout: 30 * time.Second,
}
client := &http.Client{Transport: transport}
for url := range linkChan {
resp, err := client.Get(url)
if err != nil {
fmt.Printf("Fail url: %s\n", url)
continue
}
// 必须读取并关闭 Body，否则连接可能无法正确释放（即使 DisableKeepAlives）
body, err := io.ReadAll(resp.Body)
resp.Body.Close() // 仍需调用，确保底层资源清理
if err != nil {
fmt.Printf("Fail reading url: %s\n", url)
continue
}
hasRemCode := strings.Contains(string(body), "googleadservices.com/pagead/conversion.js")
fmt.Printf("Done url: %s\t%t\n", url, hasRemCode)
}
}⚠️ 重要注意事项：
- DisableKeepAlives: true 是治本之策，适用于“单次请求、多域名、低频复用”的场景（如扫描、探测、一次性抓取）。若需访问少量高频域名（如 API 聚合），应改用 MaxIdleConnsPerHost 限流而非全局禁用。
- resp.Body.Close() 不可省略：即使禁用 Keep-Alive，不关闭 Body 仍会导致底层连接未被标记为可回收，且可能阻塞 transport 内部 goroutine。
- 避免使用已弃用的 ioutil.ReadAll（Go 1.16+），推荐 io.ReadAll（需导入 "io" 包）。
- 若需更高性能与内存可控性，可进一步结合 io.Discard 直接丢弃无需内容的响应体：
_, _ = io.Copy(io.Discard, resp.Body) // 零内存拷贝丢弃 resp.Body.Close()
- 生产环境建议添加超时控制：
client := &http.Client{ Transport: transport, Timeout: 10 * time.Second, }
总结：Go 的 HTTP 内存增长问题本质是连接管理策略与使用场景错配所致。通过显式定制 http.Transport，开发者可精准控制连接生命周期，在保证功能的同时杜绝内存泄漏。记住——不是 Go 不释放内存，而是你没告诉它“不需要再留着这个连接了”。
