go 的 http.client 本身无需手动释放，它不持有需显式关闭的底层连接；但通过它获取的 *http.response 必须调用 resp.body.close() 以释放 tcp 连接等资源，否则将导致连接泄漏。
go 的 http.client 本身无需手动释放，它不持有需显式关闭的底层连接；但通过它获取的 *http.response 必须调用 resp.body.close() 以释放 tcp 连接等资源，否则将导致连接泄漏。
在 Go 中，http.Client 是一个轻量级、无状态的结构体，设计上并不需要也不支持显式“释放”或“关闭”操作。它本身不直接持有网络连接、文件描述符或内存缓冲区等需手动管理的资源。其核心职责是配置请求行为（如超时、重定向策略）并委托给底层 Transport（通常是 http.DefaultTransport 或自定义实例）执行实际的 HTTP 通信。
真正需要关注资源释放的环节，是每次 HTTP 请求返回的 *http.Response：
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
},
}
resp, err := client.Get("https://api.example.com/data")
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close() // ✅ 关键：必须调用，否则连接可能无法复用甚至泄漏
body, err := io.ReadAll(resp.Body)
if err != nil {
log.Fatal(err)
}
// 处理 body...⚠️ 注意：resp.Body.Close() 不仅释放底层 TCP 连接（供 Transport 复用），还防止 goroutine 泄漏（net/http 内部会启动读取协程）。若忽略此步，尤其在高并发场景下，可能导致 too many open files 错误或连接池耗尽。
此外，http.Client 应被复用而非频繁重建——因为它的 Transport 字段通常维护着连接池（如复用的 HTTP/1.1 连接或 HTTP/2 流），频繁创建新 Client 会导致连接池冗余、内存浪费，甚至绕过连接复用机制。官方文档明确建议：
Clients should be reused instead of created as needed.
如果你基于 http.Client 封装了自定义客户端（例如嵌入 http.Client 并额外持有数据库连接、TLS 配置缓存、日志句柄等），则应在该类型中提供显式的 Close() 方法，并在文档中明确要求使用者调用：
type MyHTTPClient struct {
*http.Client
customCache *sync.Map
logger *log.Logger
}
func (c *MyHTTPClient) Close() error {
// 清理自定义资源
c.customCache = nil
c.logger = nil
return nil
}✅ 总结：
- http.Client 本身无需 Close()，GC 会自动回收；
- 每次请求后务必 defer resp.Body.Close()；
- 优先复用 http.Client 实例，避免滥用 &http.Client{}；
- 自定义客户端若持有外部资源，需自行实现并文档化 Close() 行为。
