http.defaultclient高并发下易出问题，因默认maxidleconns=100、maxidleconnsperhost=2，导致连接争抢、延迟飙升、超时频发；需显式配置transport、加限流、正确处理body和context。
为什么 http.DefaultClient 在高并发下容易出问题
默认客户端复用连接，但底层 http.Transport 的连接池参数保守：默认 MaxIdleConns 是 100，MaxIdleConnsPerHost 是 2。当并发请求猛增（比如 500+ goroutine 同时发请求），大量连接卡在等待空闲连接上，表现就是延迟飙升、超时频发，甚至出现 net/http: request canceled (Client.Timeout exceeded while awaiting headers)。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式配置
http.Transport，把MaxIdleConns和MaxIdleConnsPerHost设为足够大（如 2000），避免连接争抢 - 设置
IdleConnTimeout（如 30s）防止长连接堆积，同时配合TLSHandshakeTimeout防止 TLS 握手卡死 - 禁用 HTTP/2（
ForceAttemptHTTP2: false）可降低某些代理或老旧服务下的偶发 hang 问题
用 sync.WaitGroup + context.WithTimeout 控制并发请求生命周期
直接起一堆 goroutine 调用 http.Get 很危险：没超时控制会永久阻塞，没统一等待机制会导致主 goroutine 提前退出，漏掉结果或 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout包裹每个请求，确保单个请求不拖垮整体 - 用
sync.WaitGroup计数，而不是靠 channel 缓冲区大小来“猜”是否完成 - 错误要收集，但别让一个失败的请求
return掉整个 goroutine 而不调用wg.Done()—— 这会导致wg.Wait()永远卡住
示例关键片段：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() req, _ := http.NewRequestWithContext(ctx, "GET", url, nil) resp, err := client.Do(req)
goroutine 数量不是越多越好：用 semaphore 限流比盲目开 1000 个更稳
无限制起 goroutine 看似“充分利用并发”，实际常触发系统级瓶颈：文件描述符耗尽（too many open files）、内存暴涨、DNS 查询被限频、目标服务反爬封禁。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用轻量信号量（如
golang.org/x/sync/semaphore）控制最大并发数，常见值是 20–100，取决于目标服务吞吐和本地资源 - 避免用带缓冲 channel 模拟信号量（如
make(chan struct{}, N)），它无法与context取消联动，容易泄漏等待 goroutine - 把限流逻辑放在请求发起前，而不是在 goroutine 内部 —— 否则限流失效
JSON 解析和重试逻辑必须放在 goroutine 内部，不能共享 io.ReadCloser
常见错误：多个 goroutine 共享同一个 resp.Body，然后各自调用 json.NewDecoder(resp.Body).Decode(...) —— 第二个 decode 就会读到 EOF 或乱码，因为 Body 是一次性流，不可重复读。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个 goroutine 必须独立读取并关闭自己的
resp.Body，读完立刻resp.Body.Close() - 重试应基于新请求（新建
*http.Request），而非对已关闭或已读完的Body重试 - 若需多次使用响应体（比如先校验状态码，再解析 JSON），用
io.ReadAll先存成[]byte，再分别解析或校验
真正容易被忽略的是：即使用了 context 超时，如果忘记 resp.Body.Close()，底层连接不会归还给连接池，久而久之连接池就“僵死”了 —— 这类泄漏在压测中往往第二天才暴露。
