Python 爬虫的性能瓶颈绝大多数时候不在 CPU 计算，而在网络 IO 等待、页面解析开销、无效重复请求和资源浪费上。针对爬虫全链路的各个环节，下面整理了 20 个可直接落地的性能优化技巧，覆盖请求架构、网络传输、页面解析、缓存去重、工程化部署等维度，帮助你将爬虫效率提升数倍甚至一个数量级。
一、并发架构：从根源提升吞吐
1. 用异步 IO 替代同步请求模型
爬虫是典型的 IO 密集型任务，同步 requests 库会在每个请求处阻塞等待，CPU 大量时间处于空闲状态。使用 aiohttp 基于 asyncio 实现异步请求，可以在单个线程内同时挂起上百个请求，网络利用率提升 10~100 倍。
- 适用场景：大批量页面抓取、接口轮询
- 注意：异步代码需全程异步，不能穿插同步阻塞操作，否则会卡住整个事件循环。
2. 线程池 / 进程池按需选型
如果不想重构异步代码，用 concurrent.futures 也能快速提升并发：
- IO 密集型场景（绝大多数爬虫）：用 ThreadPoolExecutor 线程池，绕开网络 IO 的阻塞等待，线程数建议设为 20~100。
- CPU 密集型场景（大量文本清洗、图片处理）：用 ProcessPoolExecutor 进程池，突破 GIL 限制，进程数建议等于 CPU 核心数。
3. 分布式任务调度，突破单机瓶颈
当单机带宽、并发达到上限时，采用分布式架构横向扩展。使用 Scrapy-Redis 或 Celery + Redis/RabbitMQ 做任务队列，将 URL 任务分发到多台机器并行抓取，理论上性能随机器数量线性扩展。
- 适合场景：百万级以上 URL 的大规模采集、全站爬取。
二、网络传输：减少每一次请求的开销
4. TCP 连接池复用
每次 HTTP 请求都要经历 TCP 三次握手、TLS 握手，开销极大。使用 requests.Session（同步）或 aiohttp.ClientSession + TCPConnector（异步）复用连接，同一个域名的请求共享一条 TCP 连接，可减少 30%~50% 的请求耗时。
- 建议设置合理的连接池大小（如 limit=100），避免连接数过多撑爆服务端。
5. 启用 HTTP 压缩传输
在请求头中添加 Accept-Encoding: gzip, deflate, br，让服务端返回压缩后的响应体，通常 HTML/JSON 文本压缩率可达 70% 以上，大幅减少网络传输时间。
- 注意：requests、aiohttp 等主流库默认已开启，但自定义封装请求时需手动确认。
6. 禁用无意义的重定向
很多场景下（比如列表页、接口请求）我们不需要跟随重定向，设置 allow_redirects=False 可以直接跳过 301/302 跳转，避免额外的一次请求开销。
- 仅在需要最终落地页的场景（比如详情页跳转）才开启重定向。
7. 合理的超时与重试策略
没有超时的请求会永久卡住，拖垮整个爬虫；没有重试则会因为网络波动导致大量漏抓。
- 统一设置连接超时和读取超时（如 connect=5s, read=10s）
- 使用 tenacity 或 urllib3.Retry 实现指数退避重试，失败后逐步增加等待时间，避免加重服务端压力。
8. DNS 解析预缓存
每次请求都要进行 DNS 解析，单次耗时几十到几百毫秒。可以使用 dnspython 预解析常用域名并缓存结果，或者使用公共 DNS 服务，减少重复 DNS 查询的开销。
- 高并发场景下，也可以自定义 DNS 解析器，替换系统默认的解析逻辑。
9. 升级到 HTTP/2 协议
HTTP/2 支持多路复用，同一个 TCP 连接可以并行传输多个请求，比 HTTP/1.1 的队头阻塞问题有质的提升。使用 httpx 或支持 HTTP/2 的 aiohttp 版本开启 HTTP/2，高并发下性能提升明显。
10. 精简请求头与 Cookie
只携带必要的请求头（User-Agent、必要的鉴权字段），避免冗余的 Cookie 和自定义头。请求头越小，握手和传输开销越低，同时也能降低被反爬策略识别的概率。
三、解析效率：降低 CPU 与内存消耗
11. 用 lxml 替代默认 HTML 解析器
BeautifulSoup 默认的 html.parser 是纯 Python 实现，速度较慢。切换为 lxml 解析器（C 语言实现），解析速度可以提升 5~10 倍。
soup = BeautifulSoup(html, 'lxml')
- 更极致的选择：使用 selectolax 库，基于 Modest 引擎，解析速度比 lxml 还要快 2~3 倍。
12. 精准定位节点，避免全量 DOM 解析
不要构建完整的 DOM 树再遍历，直接用 XPath、CSS 选择器精准定位目标节点。对于只需要少量数据的页面，甚至可以用正则表达式直接提取，跳过 DOM 解析步骤。
- 原则：只解析你需要的内容，多余的 DOM 构建都是性能浪费。
13. 流式响应处理大文件 / 大页面
爬取大文件、大体积 HTML 或 CSV 时，不要一次性把整个响应加载到内存。使用 response.iter_content()（同步）或异步流式读取，分块下载、边下边处理，内存占用从 GB 级降到 MB 级。
- 适合场景：附件下载、大数据集导出接口爬取。
14. 选择更轻量的 JSON 解析库
对于接口爬虫，JSON 解析也是常见开销。使用 ujson、orjson 等 C 扩展的 JSON 库，比标准库 json 解析速度快 2~5 倍，数据量越大提升越明显。
四、缓存与去重：消灭无效请求
15. URL 去重：从源头减少重复抓取
重复请求是最常见的性能浪费。根据规模选择去重方案：
- 中小规模：用 Python set 内存去重，速度最快。
- 大规模 / 增量爬取：用 Redis 的 Set 结构持久化去重。
- 海量 URL：用布隆过滤器（pybloom-live），占用内存极低，适合十亿级 URL 去重，容忍极低的误判率。
16. 本地页面缓存，避免重复抓取
对于更新频率低的页面，使用 requests-cache 或自定义磁盘缓存，将已抓取的响应保存到本地。二次抓取时直接读取缓存，耗时从几百毫秒降到几毫秒，同时减轻目标站点压力。
- 适合场景：历史数据回溯、调试阶段反复爬取。
五、稳定性与工程化：让速度可持续
17. 并发数限流，防止反爬封禁
一味提高并发会触发反爬封禁，反而因为大量失败重试导致整体效率下降。使用 asyncio.Semaphore（异步）或令牌桶算法控制请求速率，把并发压在目标站点的封禁阈值以下，稳定持续的抓取远快于 “爬一会封一会”。
18. 高效代理池管理与预校验
代理 IP 失效是拖慢爬虫的重要原因。不要等请求超时才知道代理不可用，而是后台异步预校验代理可用性，只把有效代理投入使用。同时建立代理评分机制，优先复用速度快、成功率高的代理。
19. 内存优化：生成器 + 分批处理
不要把所有抓取结果存到一个大列表里，用生成器 yield 逐条产出数据，分批写入数据库或文件。这样内存占用不会随任务量增长，爬虫可以长时间稳定运行，也避免了大对象的 GC 开销。
20. 快速失败机制，减少无效等待
建立前置检测逻辑：对于被封禁的 IP、失效的账号、返回异常的域名，快速标记并跳过，不要等到超时再处理。比如检测到返回 403、验证码页面时，立即切换代理，而不是继续重试浪费时间。
总结
爬虫性能优化的核心逻辑从来不是 “堆并发”，而是减少 IO 等待、消灭无效请求、降低解析开销、平衡速度与稳定性。 大多数情况下，先做好连接池复用、异步化、去重和缓存这几点，就能带来数倍的性能提升；再根据业务规模逐步进阶到分布式、协议优化和工程化调优，最终实现高效且稳定的采集效果。
