应全局复用*http.Client实例并合理配置Transport参数，显式设置MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout等，及时关闭resp.Body，结合context和信号量控制并发粒度。
并发请求数量控制不当导致连接耗尽
Go 的 http.DefaultClient 默认使用 http.Transport，其 MaxIdleConns 和 MaxIdleConnsPerHost 默认值都是 100，但大量短连接并发时仍可能触发系统级限制（如文件描述符不足），表现为 dial tcp: lookup xxx: no such host 或 too many open files 错误。
实际压测中，盲目开 1000 goroutine 发起 http.Get 往往比开 50 个慢——不是因为 Go 调度慢，而是 TCP 连接建立/释放开销、TIME_WAIT 积压、DNS 解析阻塞叠加所致。
- 将
http.Transport的MaxIdleConns和MaxIdleConnsPerHost显式设为合理值（如 200），避免连接池过小反复建连 - 设置
IdleConnTimeout（如 30s）和TLSHandshakeTimeout（如 10s），防止空闲连接长期滞留 - 用
net.Dialer控制底层连接超时：KeepAlive: 30 * time.Second可缓解 NAT 超时断连
不复用 client 导致 Transport 配置失效
每次请求都新建 http.Client 实例，等于每次新建一套独立的 Transport，之前设置的连接池、超时等参数全部丢失。现象是 QPS 上不去、内存持续增长、net/http: request canceled (Client.Timeout exceeded) 频发。
必须全局复用一个 *http.Client 实例，尤其在高并发 HTTP 客户端场景下。它本身是并发安全的。
立即学习“go语言免费学习笔记（深入）”；
var httpClient = &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
},
}goroutine 泄漏：忘记处理响应 Body
HTTP 响应体未读取或未关闭，会导致底层连接无法归还给连接池，持续占用 fd 和内存。压测几分钟后出现 too many open files，大概率是这个原因。
- 所有
resp, err := httpClient.Do(req)后，必须用defer resp.Body.Close() - 即使
err != nil，也要检查resp是否非 nil 再关 Body（部分错误下 resp 仍可能有效） - 若只需状态码，仍需调用
ioutil.ReadAll(resp.Body)或io.Copy(io.Discard, resp.Body)消费完 Body
批量请求时用 context.WithTimeout + semaphore 控制并发粒度
直接启动几千 goroutine，既难控速又易打崩服务端。应结合信号量（semaphore）限流 + context 控制单请求生命周期。
Go 标准库没有内置信号量，可用带缓冲 channel 模拟：
sem := make(chan struct{}, 20) // 最多 20 并发
var wg sync.WaitGroup
for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
sem <- struct{}{} // 获取令牌
defer func() { <-sem }() // 归还令牌
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", u, nil)
resp, err := httpClient.Do(req)
if err != nil {
return
}
defer resp.Body.Close()
// 处理 resp...
}(url)}
wg.Wait()
注意：不要在循环里用 range 变量直接传参，要显式传入副本；context.WithTimeout 必须在 goroutine 内部创建，否则所有请求共享同一 deadline。
真正卡点往往不在 Goroutine 数量，而在 DNS 解析阻塞、TLS 握手延迟、服务端排队响应这些不可控环节——所以超时设置、连接复用、Body 清理这三件事，比盲目加并发更影响实际吞吐。
