ioutil.ReadAll引发goroutine泄漏：为何关闭resp.Body后仍多goroutine？

这个问题其实和Go标准库http.Client的底层实现细节有关，我来给你拆解清楚：

核心原因：HTTP客户端的连接池与后台goroutine #

Go的http.Client默认启用了连接池（通过http.Transport实现），目的是复用TCP连接以提升性能。当你执行以下操作时：

• 调用client.Do()发送请求
• 读取响应体（比如代码里的ioutil.ReadAll(resp.Body)）

客户端会自动启动后台goroutine来处理连接的后续管理工作：

• 如果服务器支持Keep-Alive，客户端会把连接放回连接池，等待后续请求复用
• 后台goroutine会负责监控空闲连接的超时时间（默认IdleConnTimeout=90秒），超时后才会关闭连接并退出goroutine

即使你调用了resp.Body.Close()，这些后台goroutine也不会立刻终止——它们需要完成连接状态的清理、等待复用超时等操作，所以在程序终止前会存在多个goroutine。

不消费resp.Body时为什么只有一个goroutine？ #

如果不读取resp.Body，Go的http客户端会判定这个TCP连接无法被复用（因为响应体未完全读取，连接处于无效状态），于是会直接关闭连接，不需要启动额外的后台goroutine来维护连接池。这种情况下，程序里只有主goroutine在运行，终止时自然只会看到一个goroutine。

关于resp.Body.Close()的补充 #

resp.Body.Close()的作用是关闭响应体的数据流，阻止继续读取响应内容，但它不会直接终止后台的连接管理goroutine。它只是告诉客户端：“我已经读完需要的内容了”，后续的连接复用/销毁逻辑还是由后台goroutine按照连接池的策略来处理。

验证方法 #

你可以在代码里加入runtime.NumGoroutine()来打印goroutine数量，比如在fetch()函数末尾延迟执行：

defer func() {
    time.Sleep(100 * time.Millisecond) // 给后台goroutine一点时间启动
    fmt.Println("当前goroutine数量:", runtime.NumGoroutine())
}()

对比消费和不消费resp.Body的情况，就能直观看到差异。

内容的提问来源于stack exchange，提问作者Nima Mohammadi