多线程比多进程快，因为爬虫是I/O密集型任务，threading在等待响应时释放GIL允许其他线程执行，而multiprocessing需为每个进程独立启动解释器、建立连接并管理内存，创建开销大20–30倍；实测1000次请求中threading（20线程）耗时约18秒，multiprocessing（4进程）约12秒（极简场景），但含解析时进程开销显著拉长耗时。
多线程在纯网络爬虫场景中效率更高，多进程通常更慢且资源开销大。
为什么多线程比多进程快？
爬虫本质是 I/O 密集型任务：90% 时间花在等待响应上，而非 CPU 计算。threading 在等待网络返回时会自动释放 GIL，让其他线程发起新请求；而 multiprocessing 每个进程都要独立启动解释器、建立连接、管理内存，光是进程创建就比线程慢 20–30 倍。
实测数据（1000 次 https://httpbin.org/get 请求）：
-
threading（20 线程）：约 18 秒 -
multiprocessing（4 进程）：约 12 秒（注意：这是极简请求；若带解析或重试逻辑，进程开销会迅速拉长耗时） -
aiohttp+asyncio（100 协程）：约 6 秒（最优解，但非本题范围）
多进程在爬虫里什么情况下反而有用？
仅当爬虫流程中混入大量 CPU 密集操作时才值得考虑，比如：
- 每页下载后立即用
lxml或BeautifulSoup做深度 DOM 解析 + 正则提取 - 同时做图片 OCR、PDF 文字提取、JS 渲染（如
playwright启动多个浏览器实例） - 需要隔离崩溃风险：某个页面解析导致子进程 segfault，不影响主流程
此时常见做法是「混合并发」：ThreadPoolExecutor 负责发请求 + 下载，ProcessPoolExecutor 负责解析——而不是全链路用 multiprocessing。
立即学习“Python免费学习笔记（深入）”；
容易踩的坑：别把 threading 当 multiprocessing 用
很多人误以为“开更多线程 = 更高并发”，结果卡死或被封 IP：
- 默认
requests不带连接池，20 个线程可能瞬间建 20 个 TCP 连接，触发目标站限流 - 没设
threading.Semaphore或使用concurrent.futures.ThreadPoolExecutor(max_workers=10)，实际并发数失控 - 共享全局变量（如计数器、缓存字典）未加
threading.Lock，导致结果错乱 - 用
threading.Thread手动管理线程却忘了.join()，主程序提前退出
