requests+threading并发变慢因阻塞i/o、gil争抢与上下文切换；需复用连接池、合理设线程数、避免time.sleep；响应极快时才考虑multiprocessing。

requests + threading 并发请求为什么反而变慢？

不是开了多线程就一定快——requests 默认使用阻塞式 HTTP 连接，线程在等待响应时仍占用资源，大量线程堆积反而触发 GIL 争抢和系统级上下文切换开销。

• 真实瓶颈常在 DNS 解析、TCP 握手、SSL 协商，而非 Python 执行本身
• 默认 requests.Session() 不复用连接，每次请求新建 TCP 连接；必须手动启用连接池：Session.mount('https://', HTTPAdapter(pool_connections=10, pool_maxsize=20))
• 线程数 ≠ 并发数：建议设为 min(32, CPU核心数 × 5)，超过后吞吐量不升反降
• 别用 time.sleep() 控制频率——它会阻塞整个线程；改用 threading.Event().wait() 或异步限流器

什么时候该切到 multiprocessing 而不是 threading？

当目标网站响应极快（lxml 处理大 HTML、正则提取多层嵌套）时，GIL 成为明显瓶颈，multiprocessing 才有收益。

• 注意进程启动开销：短任务（平均
• multiprocessing.Pool 的 maxtasksperchild 建议设为 100–500，防内存缓慢泄漏（尤其用了 lxml 或全局缓存）
• 进程间不能共享 requests.Session 实例，每个子进程需独立初始化带连接池的 Session
• 避免在子进程中打印大量日志——进程间 stdout 管道可能阻塞，改用文件或 logging.QueueHandler

asyncio + httpx 是不是“银弹”？

对 IO 密集型爬虫，asyncio + httpx.AsyncClient 通常比 threading/multiprocessing 吞吐高 3–8 倍，但前提是代码彻底异步化，且目标站不封协程特征。

Shadows Python Sensei

Python 最佳实践助手——代码规范、设计模式、性能优化、测试与类型注解。适用于编写或审查 Python 代码。

下载

• 别混用 time.sleep() 和 asyncio.sleep()：前者会阻塞整个 event loop
• httpx.AsyncClient 默认启用 HTTP/2 和连接复用，但某些 CDN（如 Cloudflare）会降级到 HTTP/1.1，需加 http2=False 参数绕过兼容问题
• 并发请求数别盲目设高：asyncio.Semaphore(100) 比直接 gather(*tasks) 更可控，防目标站拒绝连接
• 注意 httpx 的 SSL 验证行为和 requests 不同，遇到自签名证书需显式传 verify=False（仅测试环境）

真实场景下怎么选？看这三点

不用纠结“理论最优”，按实际瓶颈决策：

• 目标站响应慢（>500ms）、QPS 要求不高（threading + 连接池 + 信号量限流，最稳
• 目标站响应快（multiprocessing，注意子进程初始化开销
• 目标站支持 HTTP/2、无强反爬、QPS >100 → 上 asyncio + httpx，但务必压测 DNS 解析和 TLS 握手是否成为新瓶颈

最容易被忽略的是：所有方案都得配超时控制——timeout=(3.05, 10)（连接 3.05s，读取 10s），否则一个卡死请求会拖垮整批并发。还有，别忘了 User-Agent 轮换和 Referer 补全，很多“变慢”其实是被服务端限速了。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！