http.Client 默认不支持高并发是因为其底层 http.Transport 的连接池限制严格：默认 MaxIdleConns 和 MaxIdleConnsPerHost 均为100，IdleConnTimeout 等超时参数保守，易导致 DNS 查询失败、context deadline exceeded 及 too many open files 等问题。
为什么 http.Client 默认不支持高并发？
Go 的 http.Client 本身是线程安全的，能复用连接、支持并发调用，但默认配置下容易成为瓶颈：它底层依赖 http.Transport，而后者默认只允许最多 100 个空闲连接（MaxIdleConns），对同一 host 最多 100 个空闲连接（MaxIdleConnsPerHost），且连接超时、空闲超时都设得偏保守。实际压测时经常卡在 dial tcp: lookup xxx: no such host 或大量 context deadline exceeded，不是代码写错了，而是连接池没调好。
常见错误现象包括：
- 并发数一上 50+ 就开始超时，但 CPU 和内存都很空闲
- 请求耗时波动极大，部分请求慢几秒，其余瞬间返回
-
net.Error中频繁出现timeout或too many open files
关键调整点：
- 增大
MaxIdleConns和MaxIdleConnsPerHost（建议设为200或更高，需结合目标 QPS 估算） - 显式设置
IdleConnTimeout（如30 * time.Second），避免连接池积压失效连接 - 设置合理的
TLSHandshakeTimeout和ResponseHeaderTimeout，防止单个慢请求拖垮整个池 - 务必调用
client.CloseIdleConnections()在长期运行服务中定期清理（尤其在配置变更后）
用 sync.WaitGroup + goroutine 控制并发请求数量
盲目起成千上万个 goroutine 发请求，不仅无法提升吞吐，还会因调度开销和连接争抢反而更慢。必须做并发控制 —— 不是“越多越好”，而是“刚好够用”。
立即学习“go语言免费学习笔记（深入）”；
推荐用 sync.WaitGroup 配合带缓冲的 channel 实现固定 worker 数量的请求分发：
func doRequests(urls []string, concurrency int) {
sem := make(chan struct{}, concurrency)
var wg sync.WaitGroup
<pre class='brush:php;toolbar:false;'>for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
sem <- struct{}{} // 获取信号量
defer func() { <-sem }() // 释放
resp, err := http.Get(u)
if err != nil {
log.Printf("failed to fetch %s: %v", u, err)
return
}
defer resp.Body.Close()
// 处理响应...
}(url)
}
wg.Wait()}
注意点：
- 不要把
url直接闭包进 goroutine —— 必须传参或显式拷贝，否则所有 goroutine 共享同一个循环变量值 - 信号量 channel 缓冲大小即最大并发数，建议根据后端承载能力（如目标 API 的限流阈值）设定，通常 10–50 是较安全起点
- 如果请求间有依赖或需按序返回结果，改用
errgroup.Group更合适（它内置 cancel 和 error 聚合）
如何避免 context.DeadlineExceeded 频发？
HTTP 请求超时必须由 context 控制，不能只靠 http.Client.Timeout。后者只作用于整个请求生命周期（从 dial 到 body read 完），而真实场景中你更关心“这个请求最多花多久”，包括 DNS 解析、TLS 握手、首字节等待等环节。
正确做法是每个请求单独带 context，并合理拆分超时阶段：
- 用
context.WithTimeout(ctx, 5*time.Second)控制整体上限 - 若已知后端响应快（如内部服务），可进一步用
http.NewRequestWithContext+context.WithDeadline做更精细控制 - 避免全局复用一个 long-lived context（比如
context.Background()）直接传给所有请求 —— 一旦某次请求卡住，后续所有请求都会被它拖死
示例：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Printf("request %s timed out", url)
}
return
}要不要用第三方库如 fasthttp？
如果你的场景是纯 HTTP 客户端高频调用（比如爬虫、API 网关、批量健康检查），且不需要完整 HTTP/2、CookieJar、RedirectPolicy 等高级特性，fasthttp 确实能带来 2–5 倍性能提升：它零分配解析、复用 byte.Buffer、跳过 net/http 的 interface 抽象层。
但代价明显：
- 不兼容标准库
http.Handler接口，服务端不能直接替换 - 没有内置 TLS 重协商支持，某些企业级 HTTPS 环境会握手失败
- 文档弱、生态小，出问题难 debug（比如自定义
DialContext行为和 net/http 不一致） - 并发安全需自行保证：它的
fasthttp.Client不是 goroutine-safe 的，必须每个 goroutine 用独立实例或加锁
结论：新项目、追求极致吞吐、协议简单 → 可试；已有系统、需稳定维护、调用外部复杂 API → 优先调优标准 http.Client。
真正难的从来不是“怎么并发”，而是“怎么让并发不变成雪崩”——连接池参数、超时分级、信号量粒度、错误隔离，每一处配错，都可能让 100 并发比 10 并发还慢。
