Golang并发爬虫实战：goroutine池抓取多个URL

本文深入剖析了Golang并发爬虫实践中最易被忽视却致命的三大陷阱：无节制启动goroutine导致内存暴涨与崩溃、HTTP客户端未全局复用引发连接耗尽与超时频发、错误处理粗放致使可恢复请求大量丢失；通过引入信号量限流、复用并精细配置http.Client、按错误类型精准重试、强制读取/关闭响应体等实战方案，揭示真正制约高并发稳定性的并非并发模型本身，而是HTTP协议细节在大规模goroutine协同下的连锁失效——每一条看似微小的疏漏，都可能在数分钟后引爆整个系统。

goroutine 泄漏：不加控制地起 goroutine 必崩

并发爬虫最常踩的坑不是性能差，而是程序跑着跑着内存爆了、CPU 拉满、最后 panic: runtime: out of memory。根本原因是没限制并发数，每个 URL 都 go fetch(url)，几千个 URL 就起几千个 goroutine，而 HTTP 客户端连接、DNS 解析、TLS 握手全在背后排队堆积。

实操建议：

• 永远不用裸写 go fetch(url)，必须套进池里——用 semaphore.NewWeighted(n)（golang.org/x/sync/semaphore）或带缓冲的 channel 做并发闸门
• 哪怕只设 n = 10，也能把 goroutine 数压到两位数，同时避免目标站封 IP 或触发限流
• 别信“goroutine 很轻”，它默认栈 2KB，上万 goroutine 光栈就吃掉 20MB+，加上 net/http 的连接池和 TLS 状态，实际开销远超预期

HTTP 客户端复用：不重用 http.Client 就是自找超时和连接耗尽

每次请求都 new 一个 http.Client，会反复创建底层 http.Transport，导致连接无法复用、DNS 缓存失效、TLS 会话不复用，最终表现是大量 context deadline exceeded 或 dial tcp: lookup failed。

实操建议：

• 全局复用一个 *http.Client，设置合理的 Timeout、IdleConnTimeout 和 MaxIdleConnsPerHost
• 例如：client := &http.Client{Timeout: 10 * time.Second}，再配 Transport 时设 MaxIdleConnsPerHost: 100，否则默认 2，连 3 个 URL 就卡住
• 别在 goroutine 里改 client.Timeout —— 它不是并发安全的；要差异化超时，用 ctx.WithTimeout() 传进 client.Do(req.WithContext(ctx))

错误处理不落地：忽略 io.EOF、net.ErrClosed 和重试逻辑

真实网络环境里，resp, err := client.Do(req) 失败太常见：DNS 挂了、对方关了连接、中间代理截断、甚至 TLS 版本不匹配。但很多人只判 err != nil 就跳过，结果丢掉大量可恢复请求。

实操建议：

• 区分错误类型：对 url.Error 看 Err 字段，net.OpError 判 Timeout()，net.ErrClosed 可重试，http.ErrUseLastResponse 要手动读 resp.Body
• 简单重试用 for i := 0; i + time.Sleep(100 * time.Millisecond)，别用指数退避搞复杂——爬虫不是金融交易系统
• 务必 defer resp.Body.Close()，否则连接永远不归还给连接池，MaxIdleConnsPerHost 形同虚设

响应体读取不完整：不读完 resp.Body 就丢弃，连接池直接瘫痪

写 if resp.StatusCode == 200 { parse(resp.Body) } 然后不管 else 分支，或者解析出错就 return，会导致 resp.Body 没被读完或没关闭。后果是：该连接卡在 idle 状态，后续请求拿不到新连接，Client 最终阻塞在 transport.roundTrip。

实操建议：

• 无论成功失败，都要确保 resp.Body 被读完或关闭。最稳妥是 io.Copy(io.Discard, resp.Body) 再 Close()
• 如果只想要状态码和 header，用 resp, err := client.Head(url)，它不传 body，省带宽也省连接
• 别用 strings.NewReader(string(body)) 二次解析——body 是 io.ReadCloser，转 string 会吃光内存，大页面直接 OOM

真正难的不是并发模型，是 HTTP 协议细节在高并发下的连锁反应。比如一个没关的 Body，可能让整个连接池在 5 分钟后才超时释放——而这 5 分钟里，你还在不断起新的 goroutine。

本篇关于《Golang并发爬虫实战：goroutine池抓取多个URL》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！