核心是控制并发规模而非盲目启goroutine；用带缓冲chan作信号量（如sem := make(chan struct{}, 10)）限制同时活跃worker数，避免瞬间启动过多goroutine导致DNS耗尽、连接超时或429错误。
Go 语言实现并发爬虫本身不难，难在控制并发规模、避免被封、处理任务失败与重试、以及调度逻辑不阻塞——核心不是“怎么开 goroutine”，而是“怎么管住它们”。
用 sync.WaitGroup + chan 控制并发数，别直接起几百个 goroutine
常见错误是遍历 URL 列表时对每个 URL 起一个 go crawl(url)，结果瞬间启动上千 goroutine，DNS 耗尽、连接超时、目标站直接 429。正确做法是用带缓冲的 chan 做信号量，限制同时活跃的 worker 数量：
示例关键结构：
sem := make(chan struct{}, 10) // 最多 10 并发
for _, url := range urls {
sem <- struct{}{} // 阻塞直到有空位
go func(u string) {
defer func() { <-sem }() // 释放
crawl(u)
}(url)
}注意：sem 必须是值传递或闭包捕获正确变量，否则所有 goroutine 共享同一 url；defer 位置必须在 goroutine 内部，不能放在外层循环里。
立即学习“go语言免费学习笔记（深入）”；
context.Context 是唯一靠谱的超时与取消机制
HTTP 请求、解析、甚至 DNS 查询都必须绑定 context.WithTimeout，否则单个卡死请求会拖垮整个 worker 池。别用 time.AfterFunc 或全局 timer 杀 goroutine——无法清理资源，且可能引发 panic。
典型用法：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
if ctx.Err() == context.DeadlineExceeded {
log.Printf("timeout on %s", url)
return
}所有下游调用（如 io.ReadAll、html.Parse）也应检查 ctx.Err()，尤其解析大页面时容易卡住。
用 map[string]struct{} 去重比布隆过滤器更实际
初学者常过早引入 gobitset 或 roaring 做去重，但实际场景中，URL 去重要求不高（不需亿级）、内存够用（百万 URL ≈ 100MB），纯内存 map[string]struct{} 更简单可靠：
- 插入和查询都是 O(1)，无哈希碰撞风险（Go map 已优化）
- 无需序列化/反序列化，避免
encoding/gob的 panic 边界 - 配合
sync.Map可安全并发读写，但注意：只在读多写少时用；若写频繁，用mutex + map更可控
去重 key 推荐标准化：去掉 fragment、统一 scheme、小写 host，例如 normalize("https://EXAMPLE.COM/foo#bar") → "https://example.com/foo"。
任务队列别自己造轮子，用 channel + select 实现轻量调度
不需要 Redis 或 Kafka——简单爬虫的任务调度，靠一个 chan *Task 就够。难点在于如何让 worker 主动“要任务”，而不是被动“被派任务”：
推荐模式：
tasks := make(chan *Task, 1000)
for i := 0; i < 5; i++ {
go worker(tasks)
}
// 生产者往 tasks 发送新任务
tasks <- &Task{URL: "https://a.com"}worker 内部用 select 支持退出信号、超时、任务接收三路复用：
func worker(tasks <-chan *Task) {
for {
select {
case t, ok := <-tasks:
if !ok { return }
process(t)
case <-time.After(30 * time.Second):
// 空闲太久，可选退出或上报
return
}
}
}注意：tasks channel 容量不宜过大（如设为 10000），否则内存堆积、OOM 风险高；也不宜过小（如 1），导致生产者频繁阻塞。
真正复杂的是失败重试策略：不要固定重试 3 次，而应按 HTTP 状态码分级（404 不重试，503 指数退避，连接拒绝加 jitter），这部分逻辑必须内聚在 process() 里，不能甩给调度层。
