Go并发爬虫：Goroutine与限速实战技巧

本文深入剖析了Go并发爬虫中因goroutine泄漏引发OOM的典型陷阱——核心问题在于HTTP请求后未及时读取响应体并关闭resp.Body，导致连接池阻塞、goroutine持续堆积；文章直击痛点，强调无论是否需要响应内容，只要调用了http.Do或http.Get，就必须显式调用resp.Body.Close()，否则看似轻量的爬虫会悄无声息地耗尽内存，让你在排查性能瓶颈时少走无数弯路。

goroutine 泄漏导致爬虫内存暴涨

并发爬虫跑着跑着就 OOM，八成不是数据量大，是 goroutine 没收干净。常见于用 http.Get 发请求后，没读完响应体就直接 return，底层连接池会卡住，后续所有依赖该连接的 goroutine 都悬着。

实操建议：

• 每次调用 http.Do 或 http.Get 后，必须显式调用 resp.Body.Close()，哪怕你只取状态码
• 别在 select 里丢掉 case 分支——超时或取消时，要同步停止发请求、关闭管道、回收 goroutine
• 用 pprof 快速验证：访问 /debug/pprof/goroutine?debug=2，看是不是大量 net/http.(*persistConn).readLoop 卡在 waiting

限速控制不能只靠 time.Sleep

time.Sleep 在高并发下既不准又浪费资源：100 个 goroutine 同时 sleep 100ms，实际可能有 99 个在空等，CPU 毛刺高，还压不住 QPS。

实操建议：

• 用 rate.Limiter（来自 golang.org/x/time/rate），它基于 token bucket，支持突发和匀速两种模式
• 初始化时别写死 rate.Every(100 * time.Millisecond)——这个等价于每秒 10 次，但没考虑突发；更稳妥的是 rate.NewLimiter(rate.Limit(10), 3)，允许最多 3 次突发
• 在真正发请求前调用 limiter.Wait(ctx)，而不是 sleep 后再发——这样能自然融入上下文取消逻辑

URL 去重和任务分发容易踩 map 并发写 panic

多个 goroutine 同时往一个 map[string]bool 里写已抓取 URL，不出几秒就 fatal error: concurrent map writes。

实操建议：

• 别手写带锁 map，直接用 sync.Map 存已访问 URL，读多写少场景下性能不差
• 更推荐把去重逻辑前置：用 chan string 做任务队列，由单个 goroutine 消费、查重、去重后再派发，避免下游重复判断
• 如果要用布隆过滤器（比如 github.com/yourbasic/bloom），注意它不支持并发写，得包一层 sync.Mutex

HTTP 客户端复用与超时设置不对，连接池打满

每个请求都 new 一个 http.Client，很快就会报 dial tcp: lookup xxx: no such host 或 too many open files——其实是底层连接没复用，文件描述符耗尽。

实操建议：

• 全局复用一个 http.Client 实例，设置 Transport 的 MaxIdleConns 和 MaxIdleConnsPerHost，例如都设为 100
• 必须设 Timeout、IdleConnTimeout、TLSHandshakeTimeout，否则 DNS 卡住或服务端不响应时，连接永远挂在那里
• 别信默认值：http.DefaultClient 的 Timeout 是 0（无限等待），生产环境必须覆盖

真正难的不是启动一堆 goroutine，而是让它们在错误、超时、取消、重试之间自然退场。连接没关、令牌没取、管道没关、context 没传到底——这些地方漏一个，爬虫跑一天就变僵尸进程。

今天关于《Go并发爬虫：Goroutine与限速实战技巧》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！