直接用 time.sleep() 在循环里限速不靠谱，因为 DNS 解析、连接建立、SSL 握手等耗时未被纳入延迟控制，导致请求实际集中爆发；且遇 429 或超时无法自动补偿，易引发后续请求扎堆。
为什么直接用 time.sleep() 在循环里限速不靠谱
因为爬虫通常不是单请求线性执行——用 requests 同步发 10 次，每次 sleep(1)，看似每秒 1 次，但 DNS 解析、连接建立、SSL 握手、响应读取这些耗时全算在 sleep 外，实际并发压力可能集中在某几百毫秒内爆发。更麻烦的是，如果目标域名返回 429 或连接超时，sleep 不会自动补偿，反而导致后续请求扎堆。
用 scrapy.downloadermiddlewares.retry.RetryMiddleware 配合自定义延迟策略
Scrapy 原生支持按域名动态控速，关键在 DOWNLOAD_DELAY 和 AUTOTHROTTLE_ENABLED 的组合使用，但默认只对整个爬虫生效。要精确到域名，得靠中间件拦截 request.meta['domain'] 并注入延迟：
- 在
settings.py中启用：AUTOTHROTTLE_ENABLED = True，并设AUTOTHROTTLE_START_DELAY = 1.0 - 写一个 downloader middleware，在
process_request中检查request.url，匹配特定域名（如"example.com"），然后设置request.meta['download_slot'] = 'example.com' - 为该 slot 单独配置延迟：
DOWNLOAD_DELAY_example.com = 2.5（需在 middleware 中读取并覆盖slot.delay） - 注意：Scrapy 的 slot 是按
download_slot字符串隔离的，不同域名必须用不同 slot 名，否则限速会串扰
用 httpx.AsyncClient + asyncio.Semaphore 控制每域名并发数
纯异步场景下，time.sleep() 会阻塞整个 event loop，必须用 await asyncio.sleep()；但光 sleep 还不够，得限制同一域名的请求数上限，否则仍可能瞬间打出 10 个连接：
semaphores = {}
async def get_with_domain_limit(client, url):
domain = urlparse(url).netloc
if domain not in semaphores:
semaphores[domain] = asyncio.Semaphore(2) # 每域名最多 2 并发
async with semaphores[domain]:
await asyncio.sleep(1.0) # 请求前固定延迟
return await client.get(url)
- 注意
asyncio.Semaphore是 per-domain 实例，不能共用一个全局 semaphore -
await asyncio.sleep()必须在async with之后，否则延迟不绑定到具体域名请求上 - 如果目标服务器有 IP 级限流，还需配合
rotate_user_agent或代理池，但这是另一层问题
如何验证限速是否真正生效而不是“看起来慢”
光看日志时间戳没用——得抓真实 TCP 连接行为。用 tshark 或 Wireshark 过滤目标域名的 SYN 包间隔：
立即学习“Python免费学习笔记（深入）”；
tshark -i any -f "host example.com and tcp port 443" -T fields -e frame.time_epoch | awk '{if(NR>1) print $1-prev; prev=$1}'
- 输出值应稳定在你设定的延迟附近（比如 2.0±0.3 秒），而非忽大忽小
- 如果发现多个 SYN 几乎同时发出，说明 semaphore 没生效或 slot 配置重复
- 某些 CDN（如 Cloudflare）会在 TLS 握手阶段就丢包或重置连接，这种情况下即使代码限速了，网络层仍可能触发重试风暴——得加
backoff_factor和最大重试次数兜底
真实限速的核心不在“让程序停一会儿”，而在“让每个域名的连接生命周期可控”。很多脚本卡在 DNS 缓存、HTTP/2 多路复用、连接池复用这些细节上，结果调了 5 分钟 sleep，发现是 requests.Session() 默认 keep-alive 把连接撑爆了。
