多线程没提速主因是任务类型错配：requests.get等IO操作适合多线程，但lxml解析、正则匹配、pandas合并等CPU密集型操作受GIL限制，需改用multiprocessing。
多线程没提速，大概率不是代码写错了，而是任务类型和锁机制不匹配——requests.get这类网络请求本就该用多线程，但如果你实际在做解析-heavy 或 CPU-heavy 操作（比如用 lxml 解析超大 HTML、跑正则匹配巨量文本、或做本地数据聚合），那 GIL 真的会卡住你。
为什么 threading.Thread 对某些爬虫没提速
Python 的 GIL 不会阻塞系统调用（如 socket recv），所以纯 IO 等待时多线程能并发；但一旦解析逻辑开始大量占用 CPU，线程就会被 GIL 轮转调度，无法真正并行。常见误判场景：
- 你以为只是“发请求+取文本”，结果
BeautifulSoup(response.text, 'lxml')在单线程里默默吃掉 80% 时间 - 你把所有 URL 丢进一个大列表，然后每个线程都去
re.findall(...)扫一遍几 MB 的 HTML 字符串 - 你用
pandas.concat在主线程里合并 100 个 DataFrame，成了新的瓶颈
此时看 top 或任务管理器，会发现 Python 进程 CPU 占用始终卡在 ~100%，而不是随线程数线性上涨——这就是 GIL 在起作用。
什么时候必须换 multiprocessing
满足以下任一条件，multiprocessing 就比 threading 更合适：
立即学习“Python免费学习笔记（深入）”；
- 解析阶段用了
lxml、regex（尤其带re.compile(...).finditer()）、json.loads()处理超长字符串 - 需要对响应内容做数值计算、编码转换（如 base64 decode 后做图像处理）
- 你用的是 C 扩展模块（如
numpy数组运算），且逻辑无法被 asyncio 覆盖
注意：multiprocessing 不能直接共享全局变量或未序列化的对象（比如活的 requests.Session 实例），传参必须是 pickleable 的。
threading → multiprocessing 的最小改造点
不需要重写整个逻辑，只改三处就能切换：
- 把
import threading换成import multiprocessing as mp - 把
threading.Thread(target=worker, args=(url,))换成mp.Process(target=worker, args=(url,)) - 把
threads = []; t.start(); t.join()改为procs = []; p.start(); p.join()
但要注意：进程启动开销比线程大，所以别盲目开 100 个 Process。实测中，CPU 核心数 ±2 是较优区间（比如 8 核机器用 6–10 个进程）。另外，mp.Queue 或 mp.Manager().list() 才能跨进程传结果，别指望全局 list 自动同步。
容易被忽略的性能断点
即使换成 multiprocessing，下面这些地方仍可能拖慢整体速度：
-
requests.Session()没复用：每个进程都新建 session，等于放弃连接池，TCP 握手重复 10 次 - 日志写文件没加锁：多个进程同时
open('log.txt', 'a')写，内容错乱甚至丢行 - 输出路径冲突：10 个进程都往
data.json写，最后只剩一个进程的数据 - 没设
timeout：某个页面卡死，整个进程挂住，其他任务干等
最隐蔽的问题其实是 DNS 缓存——默认每个进程独立查 DNS，高频请求下可能触发本地 resolver 限速。解决方案是提前用 socket.gethostbyname() 解一次，把 IP 直接拼进 URL，或者用 urllib3.util.connection.create_connection 控制底层连接。
