高并发爬虫需可控并发、连接复用、流式解析与反爬伪装:用自定义http.Client配连接池和超时,chan struct{}限流,goquery流式解析HTML,轮换UA并加随机延迟。
http.Get 本身是同步阻塞的,直接用它开成百上千个 goroutine 看似并发,实则极易触发连接耗尽、DNS 阻塞、目标站限流甚至本机 too many open files 错误。真正的高并发爬虫不是“多开”,而是“可控地多开 + 复用 + 降噪”。
*http.Client 配连接池,别裸调 http.Get
默认的 http.Get 内部使用全局默认客户端,没有超时、无连接复用、无空闲连接管理,100 个并发请求可能瞬间建立 100 个 TCP 连接,还全不释放。
*http.Client,重点配 Transport
MaxIdleConns 和 M
axIdleConnsPerHost 要设(比如都设为 100),否则连接用完就新建,压根不复用Timeout(如 10 * time.Second),否则一个卡死请求会拖垮整个 worker 池IdleConnTimeout 建议设为 30 * time.Second,避免长连接被服务端主动断开后还傻等client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
},
}sync.WaitGroup 控总数sync.WaitGroup 只能等结束,不能限并发;无缓冲 chan struct{} 容易导致 goroutine 泄漏或死锁;真正稳定的做法是固定容量的信号量 channel。
sem := make(chan struct{}, 100),容量即最大并发数sem (阻塞直到有空位)
(释放一个位置)
,且用 defer 包裹,防止 panic 后没释放
sem := make(chan struct{}, 100)
for _, url := range urls {
go func(u string) {
sem <- struct{}{} // 获取令牌
defer func() { <-sem }() // 保证释放
resp, err := client.Get(u)
if err != nil {
log.Printf("fetch fail %s: %v", u, err)
return
}
defer resp.Body.Close()
// ...处理响应
}(url)}
解析 HTML 别用 io/ioutil.ReadAll,优先用 io.Copy 或流式解析
抓取大页面(比如电商详情页 >2MB)时,ioutil.ReadAll(resp.Body) 会把整页加载进内存,100 并发 × 2MB = 200MB 内存瞬时占用,GC 压力陡增,容易 OOM。
goquery.NewDocumentFromReader 直接传 resp.Body,它内部按需读取,不全载io.Copy(ioutil.Discard, resp.Body) 忽略内容,或写入临时文件ReadAll + 字符串拼接 —— Go 的字符串是不可变的,每次 + 都分配新内存哪怕只是测试站,不加基础伪装也会被 nginx 层直接 403 或 429。真实站点更敏感。
User-Agent(至少轮换 3–5 个主流浏览器 UA 字符串)client.Do(req) 前,用 req.Header.Set("User-Agent", ua)
time.Sleep(time.Duration(rand.Intn(300)+200) * time.Millisecond)
req.Header.Set("Referer", "https://example.com/") 和 req.Host = "example.com"(绕过 CDN 或 WAF 的 Host 校验)Go 爬虫最难的从来不是“怎么并发”,而是“怎么让并发不把自己和对方搞崩”。连接复用、信号量、流式读取、UA 轮换——这四点漏掉任意一个,在千级 URL 规模下基本就跑不稳。真正上线的爬虫,80% 的代码都在做这些“不酷但管用”的控制逻辑。