限流是关键,需用带缓冲的channel模拟信号量控制并发数,避免内存暴涨、IP被封、DNS耗尽等问题,核心在于可控并发而非无节制启动goroutine。
goroutine + channel 控制并发数,别直接起成百上千个无节制启 goroutine 是最常见错误:内存暴涨、被目标站封 IP、DNS 耗尽。必须限流。核心不是“能并发”,而是“可控并发”。semaphore 本质就是带缓冲的 chan struct{},每发一个请求前先 ,完成后 sem 。
sem := make(chan struct{}, 10) 表示最多同时 10 个请求func() { 中,否则漏释放会卡死
time.Sleep 模拟限速——它不释放 goroutine,只是挂起;真限速要用 time.Ticker 配合 channelhttp.Client 必须复用,且设置超时和连接池每次 new http.Cl 会新建底层 Transport,导致 TCP 连接无法复用、TIME_WAIT 爆满、DNS 查询重复。默认 client 的 
DefaultTransport 虽然有连接池,但参数极保守(MaxIdleConns=100),爬虫场景下远远不够。
http.Client,并配置 Transport:MaxIdleConns 和 MaxIdleConnsPerHost 建议设为 200~500Timeout(总超时)、IdleConnTimeout(空闲连接保持时间)、TLSHandshakeTimeout,否则慢响应或 TLS 卡住会拖垮整个池map[string]struct{} + sync.Map,别用全局锁爬虫最耗时的不是网络,是重复请求和锁竞争。用 map[string]struct{} 存已抓 URL 是最小开销方案(struct{} 零字节),但普通 map 不支持并发读写。
sync.Map,注意它的 LoadOrStore 返回值是 value, loaded bool,要靠 loaded 判断是否已存在bolt 或 badger,但会引入 IO 延迟,需权衡net/http 错误类型杂乱:DNS 失败、连接拒绝、TLS 握手超时、HTTP 4xx/5xx、body 读取中断……全丢进重试队列只会让问题恶化。
net.OpError(连接超时、拒绝)、url.Error(timeout、EOF)、500/502/503/504 —— 但建议加退避(exponential backoff),最多重试 2~3 次err.Error() 和 URL,否则排查时根本不知道卡在哪一环真正难的不是并发模型,而是如何让每个请求既快又稳:连接复用是否生效、DNS 缓存有没有穿透、TLS 握手是否被干扰、目标站反爬策略怎么绕过——这些都得靠日志+指标+真实响应体分析,光靠 goroutine 数量解决不了。