如何使用Golang处理并发中的网络I/O_Golang并发网络请求与性能优化

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()，底层连接不会归还给连接池，久而久之连接池就“僵死”了 —— 这类泄漏在压测中往往第二天才暴露。