直接用 time.sleep 控制爬取间隔是错的，因其无法支持并发调度、失败重试、域名隔离限流，且会阻塞 goroutine、浪费资源；正确做法是为每个标准化域名分配独立 rate.limiter 实例，并透传带超时的 context。
为什么直接用 time.Sleep 控制爬取间隔是错的
它无法应对并发任务调度、失败重试、优先级调整，还会让整个 goroutine 阻塞，浪费资源。真实场景里，你不是“等几秒再发一个请求”，而是“确保每秒最多发 N 个请求，且不同域名要独立限流”。
- 用
time.Sleep会导致所有任务共享同一延迟逻辑，一旦某个 URL 报错重试，就拖慢后续全部任务 - 不同目标站点对 QPS 敏感度不同，硬编码 sleep 时间等于把
example.com和api.github.com当成同一个限流桶 - goroutine 不会因为 sleep 就自动释放，大量 pending 的 sleep 状态会堆积内存和调度开销
正确做法是用带权重与域名隔离的令牌桶，配合 channel 控制消费节奏。比如用 golang.org/x/time/rate 的 Limiter，每个域名配一个独立 *rate.Limiter 实例。
如何为不同域名分配独立限流器并复用
核心在于把域名作为 key 构建 map，避免每次请求都新建或查找失败。别用全局单例 limiter，也别在 handler 里临时 new —— 这两种都会导致限流失效或内存泄漏。
- 初始化时用
sync.Map或带读写锁的普通 map 存储map[String]*rate.Limiter - 获取 limiter 时先
Load，不存在再Store新建，参数如rate.Every(1 * time.Second)和burst=5要按域名策略配置 - 注意：不要把
http.Request.Host直接当 key，得先做标准化（去掉 port、转小写），否则api.example.com:443和API.EXAMPLE.COM会被当成两个域名
示例片段：
limiter, _ := limiters.LoadOrStore(domain, rate.NewLimiter(rate.Every(2*time.Second), 1)) 后续调用 limiter.Wait(ctx) 即可阻塞等待令牌。
立即学习“go语言免费学习笔记（深入）”；
context.Context 在排队环节必须传透的原因
爬虫排队不是纯内存操作，它常嵌套在 HTTP handler、定时任务或消息消费中，任何一环超时或取消，排队中的请求都该立刻退出，否则 goroutine 泄漏、连接堆积、重试风暴全来了。
- 所有
Limiter.Wait必须传入带 timeout 的ctx，比如ctx, cancel := context.WithTimeout(parentCtx, 30*time.Second) - 如果上游已 cancel（如用户关闭页面、K8s 发送 SIGTERM），
Wait会立即返回context.Canceled错误，你不检查就继续发请求，等于忽略信号 - 别在排队前就
http.NewRequestWithContext，而要在真正准备发起 HTTP 请求那一刻才绑定 context —— 排队阶段的 context 只管“能不能取令牌”，不关 HTTP 什么事
常见错误日志：context deadline exceeded 出现在 Limiter.Wait 而非 http.Do，说明排队卡住了，得查 limiter burst 是否设太小，或上游 ctx timeout 是否过短。
为什么不用 channel 做任务队列而选 sync.Pool + 有限长 slice
初学者容易想当然用 chan *Task 做缓冲队列，但实际压测会发现：channel 阻塞写入导致生产者卡死、GC 压力大、无法按优先级插队、扩容缩容困难。
- 高吞吐下，
chan的锁竞争比 slice+mutex 更重；尤其当消费者偶尔延迟，channel 缓冲区满后所有生产者全停摆 - 用
sync.Pool复用[]*Task切片，配合atomic.Int64计数器控制总长度（如最多存 10000 个待爬 URL），内存更可控 - 需要优先级时，slice 可以快速排序或分 bucket（如 status=200 的放 front，404 放 back），channel 无法做到
关键点：不是“有没有队列”，而是“谁控制入队节奏”。真正的排队逻辑在 limiter.Wait，而不是 channel 的容量。队列只是暂存，不是调度器。
事情说清了就结束。真正难的是域名识别的健壮性、限流参数的动态加载、以及 context 取消后残留 goroutine 的清理——这些不会报错，但会让系统在流量高峰时悄悄失联。