如何在Python爬虫中实现针对特定域名的限速抓取以保护目标服务器？

直接用 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 把连接撑爆了。