Go语言http.Client必须显式配置，因http.Get使用无超时的DefaultClient，易致DNS/TCP/TLS卡死、连接不复用、重定向失控、Body未关致fd耗尽；须定制Transport设置MaxIdleConns、MaxConnsPerHost、IdleConnTimeout等参数并配合context控制超时。
Go 语言的 http.Client 不是“用起来就完事”的黑盒，它默认行为在生产环境里容易出问题：连接不复用、超时没设、重定向失控、Body 不关导致 fd 耗尽。必须显式配置才能可靠使用。
为什么不能直接用 http.Get 发生产请求
http.Get 内部用的是 http.DefaultClient，它没有设置 Timeout，也没有定制 Transport。这意味着：
- 请求卡在 DNS 解析、TCP 连接、TLS 握手或响应读取任一环节，都会无限等待
- 空闲连接不会自动回收，
MaxIdleConns默认是 0（即不限制），但IdleConnTimeout是 0（永不超时），连接池会越积越多 - 重定向无限制，遇到跳转环路会一直循环下去
- 无法注入
context.Context，没法做请求取消或超时控制
所以，哪怕只是发一个简单 GET，也该用自定义 http.Client 实例。
必须设置的三个 Transport 参数
http.Transport 是连接复用和底层网络行为的实际控制者。以下三项不配，高并发下大概率翻车：
立即学习“go语言免费学习笔记（深入）”；
-
MaxIdleConns：建议设为 100，避免频繁建连；设为 0 表示禁用空闲连接，完全不可取 -
MaxConnsPerHost：建议与MaxIdleConns一致（如 100），否则单域名连接数会被掐死 -
IdleConnTimeout：必须设，推荐 30 秒；不设会导致 TIME_WAIT 连接堆积，最终dial tcp: lookup xxx: no such host或too many open files
示例：
tr := &http.Transport{
MaxIdleConns: 100,
MaxConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
}如何安全读取并关闭响应体
忘记 defer resp.Body.Close() 是最常见泄漏源。但仅靠 defer 不够，还要注意：
- 如果
resp.StatusCode >= 400，很多开发者会直接 return，忘了关 Body —— 必须在所有分支都关 - 用
io.ReadAll读取前先检查resp.Body == nil（极少数服务可能返回 nil Body） - 大响应体别全读进内存，改用
io.Copy或流式处理，否则 GC 压力大、OOM 风险高 - 如果只读 Header 就够了（比如查
Content-Length），可以调resp.Body.Close()立即释放连接
Context 取消必须和 Do 绑定，不能只包 Request
只对 http.NewRequestWithContext 传 context 是无效的——client.Do 才真正消费它。正确写法是：
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
defer cancel() // 注意：不是 defer resp.Body.Close() 之后再 cancel
<p>req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
if err != nil {
return err
}
resp, err := client.Do(req) // ← 这里才真正受 ctx 控制
if err != nil {
return err // 可能是 context.DeadlineExceeded
}漏掉 defer cancel() 会导致 goroutine 泄漏；cancel 太早（比如在 Do 前）会让请求直接失败。
真正难的不是写对一行 client.Do(req)，而是理解每个字段在什么阶段生效、在哪种错误路径下会失效。连接池参数只在 Transport 层起作用，超时要分 Transport 级和 Client 级，context 取消时机错 1 行，整条链路就失去控制。这些细节不抠清楚，压测时的 net/http: request canceled 和 http: aborting pending connections 就会准时出现。
