2025 年聊 Python 爬虫选库的思路已经和五年前完全不一样了。早年一提爬虫几乎所有教程都是 requests BeautifulSoup 的组合简单、直观随便找个小站就能跑通。但现在你面对的目标网站往往有动态渲染、接口加密、访问频率限制等各种机制库的种类也丰富了很多。这篇文章我想从 2025 年的视角系统拆一拆 Python 网页爬取库的现状和选型思路每个层级有哪些主流库、各自的优势和边界、我在实操中踩过的坑以及不同场景下的组合建议。想入坑爬虫、或者正在纠结怎么选库的朋友可以参考。1. 2025年的爬虫生态选库前先想清楚这四个问题1.1 经典组合为什么还在但不再够用2018 年左右入行的 Python 爬虫开发者大概率都是从 requests BeautifulSoup 这套组合开始的。这套组合能火这么多年不是没有道理requests 把 HTTP 请求的复杂度压缩到了几行代码BeautifulSoup 的 find/find_all 和 select 语法对新手极其友好。直到今天很多一次性小任务我依然会顺手用它们比如抓个接口数据、拉个静态页面的表格。但 2025 年再写爬虫情况已经变化不少。前几年前后端分离还没有这么彻底页面上的很多数据还老老实实写在 HTML 里现在你随便打开一个资讯站或电商站HTML 里常常只有一堆 script 标签和一个空壳 div真正的数据在接口里或者要靠执行一段 JavaScript 之后才出现在页面上。与此同时访问频率限制、人机验证、动态 token 这些机制基本成了标配。不是说 requests 不行了而是一个库打天下的时代结束了。1.2 按层级划分的库全景我的习惯是把爬虫工具按四个层级来理解选型的时候一层一层对号入座层级代表库主要解决什么问题请求层requests、httpx、aiohttp发送 HTTP 请求、会话保持、超时重试解析层BeautifulSoup、lxml、parsel从 HTML/XML 中提取结构化数据渲染层Playwright、DrissionPage、Selenium模拟浏览器执行脚本、处理动态页面框架层Scrapy调度、去重、并发、数据流水线的工程化整合每个层级解决一类问题。选库不是哪个最好而是当前的目标网站落在哪几个层级里。如果目标网站是纯静态 HTML请求层 解析层就够如果是前后端分离的接口数据往往只需要请求层直接打接口连解析层都可以省掉如果数据必须等 JavaScript 渲染才能拿到就得引入渲染层。1.3 选库前必须想清楚的四件事在动手安装库之前我建议先把下面四件事想明白想清楚之后选型基本就是水到渠成的事目标网站是什么形态静态 HTML、JSON 接口、还是动态渲染页面这个直接决定要不要上渲染层。预计的数据规模几十条和几百万条选型是完全不一样的。小规模任务追求简单直接大规模任务必须考虑并发、断点续爬和分布式。访问频率的容忍度目标服务器对爬虫的容忍度有多高有没有明确的速率限制这决定你要不要专门设计请求间隔和退避机制。项目需要维护多久跑一次就扔的脚本和要跑几个月的采集任务工程化程度完全不同。这四个问题想完哪些库进入候选名单基本就清楚了。下面是每一层我在 2025 年实际的选型心得。2. 请求层requests 与 httpx谁更适合作为默认选项2.1 requests可靠但留下了一些遗憾requests 到今天依然是 Python 生态里 HTTP 客户端的事实标准它最大的优点是 API 设计得足够好几乎不存在学习成本。一个典型的请求大概是这样的import requests resp requests.get( https://api.example.com/data, headers{User-Agent: Mozilla/5.0}, params{page: 1}, timeout10, ) resp.raise_for_status() data resp.json()这句话看着简单但里面值得展开的点不少。headers里自定义 User-Agent 是常规操作很多站点对默认的 python-requests 标识有过滤params可以让 requests 自动帮你做 URL 编码timeout如果不设请求可能一直挂着这在采集任务里是最容易翻车的细节之一。还有Session如果你要连续访问同一个站点的多个页面一定要用requests.Session()来复用连接和 cookie性能和稳定性都能明显提升。requests 的问题在于它停在了 够用 这个位置。它不原生支持 HTTP/2异步模式也需要靠外部生态比如grequests才能实现遇到需要高并发下载的场景就得换工具。如果你只是写一次性采集脚本requests 完全没问题但如果你打算长期维护一套爬虫它多少有点不够看了。2.2 httpx同步异步通吃HTTP/2 原生支持httpx 是近两年我用的最多的请求库它几乎完美继承了 requests 的 API 风格同时补齐了 requests 的短板。最吸引人的一点是它支持同步和异步两套写法API 几乎一致这意味着你可以先用同步方式快速验证逻辑等需要优化并发时再无缝切到异步不用重写业务代码。# 同步方式requests 用户几乎零成本迁移 import httpx with httpx.Client(http2True, timeout10) as client: resp client.get( https://api.example.com/data, headers{User-Agent: Mozilla/5.0}, params{page: 1}, ) print(resp.status_code, resp.json())# 异步方式适合批量并发采集 import asyncio import httpx async def fetch(url: str) - str: async with httpx.AsyncClient(http2True, timeout10) as client: resp await client.get(url) return resp.text async def main(): urls [https://example.com/a, https://example.com/b, https://example.com/c] results await asyncio.gather(*[fetch(u) for u in urls]) for r in results: print(len(r)) asyncio.run(main())注意with httpx.Client(...)和async with httpx.AsyncClient(...)这种写法。很多人刚开始用 httpx 时习惯直接httpx.get()这样也能跑但每次都会新建连接浪费严重。用上下文管理器创建 Client / AsyncClient 是推荐做法连接池会复用底层连接性能好很多。我实际测试过在http2True开启的情况下如果目标服务器支持 HTTP/2多路复用带来的性能提升在高并发场景下非常明显。2025 年的主流 CDN 和 Web 服务器基本都开了 H2这个参数几乎是白捡的性能。2.3 我实际使用中的选择逻辑我的选择逻辑比较简单直接新项目默认用httpxAPI 熟悉、扩展性好后面想加并发也不用换库。维护中的老项目、或目标服务器对 client 指纹特别敏感的场景可以继续用requests。某些反爬系统会看 TLS 指纹requests 因为生态很老指纹反而容易被识别。这一点上 httpx 也没有本质优势真要对付这种场景得上 curl_cffi 这类专门的库。只抓接口数据、不需要处理复杂页面时httpx 或 requests 都是够用的关键是把 headers、timeout、Session/Client 用好。提示不管用哪个请求库一定要设 timeout而且要区分 connect timeout 和 read timeout。我见过太多脚本因为漏设 timeout在目标服务器响应变慢时全部卡死只能手动 kill 进程重来。3. 解析层BeautifulSoup、lxml、parsel 三选一还是各取所长3.1 解析器的核心差异容错、速度、语法请求层拿到的是整个 HTML 源码解析层的任务是从这堆标签里把你要的数据抠出来。这个层级的三剑客各有特点BeautifulSoup最易用find、select、get_text这些方法读起来像自然语言。但它是纯 Python 实现的速度是三个里最慢的。lxml是 C 语言实现的解析引擎速度快得肉眼可见支持 XPath 和 CSS Selector但 API 偏底层写起来没那么温柔。parsel是 Scrapy 项目里单独拆分出来的解析库底层也依赖 lxml但它提供了一整套更符合爬虫场景的 APISelector对象统一了 XPath 和 CSS Selector 的写法。说个不算冷的知识parsel 的底层其实是 lxml所以它和 lxml 一样快。三者的真实差距主要在于写起来顺不顺手和容错逻辑细不细。3.2 三种库的实测手感对比同样一个任务提取页面里所有h1.title的文本三种写法分别长这样from bs4 import BeautifulSoup soup BeautifulSoup(html, html.parser) titles [h.get_text(stripTrue) for h in soup.select(h1.title)]from lxml import etree root etree.HTML(html) titles root.xpath(//h1[classtitle]/text())from parsel import Selector sel Selector(texthtml) titles sel.css(h1.title::text).getall()要我给个大致排序容错性上 BeautifulSoup lxml ≈ parsel解析速度上 lxml ≈ parsel BeautifulSoup差距可能达到一个数量级写法的爽快感上parsel 和 BeautifulSoup 都挺舒服lxml 偏裸。这里多提一句容错性。真实世界的 HTML 远比 W3C 规范里写的要脏属性缺引号、标签不闭合、嵌套错乱到处都是。BeautifulSoup 带html.parser时对这类脏 HTML 容忍度很高lxml 的 HTML 解析器容错也不错但偶尔会在某些畸形页面上抛出警告甚至直接报错。如果你要解析的来源本身就很规范比如官方文档站、接口返回的标准 XML用 lxml 完全没问题但要是面对野生的论坛页面、老旧的 CMS 系统BeautifulSoup 更让人放心。注意还有一个隐蔽的坑——解析器不同同一个选择器可能选出不同的结果。比如 lxml 对标签不闭合有自己的一套补全规则BeautifulSoup 又是另一套。所以写解析代码时最好先确认好线上页面的真实 DOM别用开发者工具里的源码直接赌选择器。3.3 数据量大时的性能优化方向如果你的任务是每天几十万页面级别的采集解析速度就不再是无所谓的事了。这一层我在实际项目里的优化顺序是这样的优先用 parsel 或 lxml它们内置的选择器引擎足够快很少需要手写正则。正则看着快但写起来容易漏边界维护成本奇高。能用 XPath 就不用 CSS Selector。XPath 能直接按文本内容定位能做条件判断CSS 做不到这些。而且 XPath 表达式在一些深层嵌套结构里比 CSS 链式选择器更短更清晰。避免在循环里反复创建 Selector 对象。把 HTML 一次性构造成 Selector 或 etree 对象后面所有的提取操作都复用这个对象比每次把一个新 HTML 字符串丢进解析器要快。3.4 不同场景的推荐组合我的经验是小项目、原型验证、目标不明确还在摸索阶段时用 BeautifulSoup 最舒服因为它的容错性和可读性让你能快速调通逻辑生产环境里数据量大、结构相对稳定的场景直接上 parsel它比 lxml 写起来舒服比 BeautifulSoup 快得多而且如果你以后要迁移到 Scrapy代码几乎不用改。如果你拿到的 HTML 结构里有多层嵌套标签且字段很多我建议在项目一开始就写一份数据提取函数比如extract_detail(html: str) - dict把每个字段的 XPath / CSS 路径集中管理。这样一旦页面改版只需改这一个函数不用在几百行代码里到处找选择器。4. 动态渲染页面Playwright 与 DrissionPage 的取舍4.1 动态渲染是 2025 年绕不开的话题用 requests 能轻松爬到的是那些服务端渲染的传统页面。现在的目标网站里动态渲染的比例越来越高页面骨架先出来真正的数据靠 JavaScript 异步填充。这种页面你如果用 requests 直接拿 HTML拿到的基本是一堆空壳和 script 路径。对于这类页面最简单的思路其实是先找接口。很多动态页面背后都有一到数个 JSON 接口打开浏览器开发者工具的 Network 面板看一会儿找到返回关键数据的那个请求直接用请求层打它。这是比上渲染层轻量得多的方案我强烈建议优先尝试。但接口这条路不是总能走通。比如接口返回的数据是加密的或者接口绑定了页面内的动态 token这时候就得上渲染层让浏览器把页面完整跑起来再从中提取内容。4.2 Playwright重量级但全面Playwright 是微软开源的浏览器自动化框架支持 Chromium、Firefox 和 WebKit通过一套统一的 API 控制真实浏览器完成页面渲染、点击、滚动、等待元素出现等操作。它的同步 API 和异步 API 都做得非常完善内置了自动等待机制可以明显减少手工 sleep 的写法。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://example.com, timeout30_000) page.wait_for_selector(h1.title) html page.content() browser.close()实际使用中Playwright 让我最省心的一点是wait_for_selector。以前用 Selenium 写脚本最难受的就是不知道页面到底什么时候加载完只能time.sleep(3)这种笨办法既浪费时间又容易误判。Playwright 会自动重试等待元素出现代码语义清楚多了。它还能拦截网络请求、伪造响应、模拟上传下载对于复杂的交互型爬取任务Playwright 基本是 2025 年的首选。4.3 DrissionPage更贴合 Python 直觉的轻量方案DrissionPage 是近两年在国内开发者圈子里口碑很好的一个库。它和 Selenium 不一样不需要单独维护浏览器驱动直接通过 Python 控制 Chromium 或 Edge提供了一套非常 Pythonic 的 APIfrom DrissionPage import ChromiumPage page ChromiumPage() page.get(https://example.com) title page.ele(.title).text实际手感上DrissionPage 比 Selenium 清爽太多查找元素不用写一长串driver.find_element(By.CSS_SELECTOR, ...)page.ele()一个方法就够了。而且它对一些常见的人机验证环境的兼容性也比多数老方案好出错概率更小。需要说明的是DrissionPage 并不是要全面替代 Selenium 或 Playwright。它的定位偏轻适合单页面快速采集、数据量不大、交互需要有限的场景。如果是复杂的多步骤流程测试、多浏览器兼容性验证Playwright 更合适。4.4 自动化浏览器资源消耗与稳定性问题用渲染层做爬虫有一个绕不开的现实问题真浏览器非常吃内存和 CPU。一个无头 Chromium 实例动辄占用几百 MB 内存如果并发开十几个浏览器实例普通开发机直接卡死。几个我踩过的坑无头模式不等于完全不可见它依然会执行页面脚本依然会被一些站点通过 JS 指纹识别。页面中的广告、图片、视频请求会拖慢整体速度能用拦截的方式尽量拦截。渲染层请求频率过高照样触发限流。浏览器工具只是换了一种请求形式不是免死金牌。提示如果你的采集脚本需要长时间运行建议用 Docker 单独跑一个浏览器容器或者用 Playwright 的chromium.launch()里配置好资源限制。别在爬虫脚本里裸开浏览器实例就跑了跑两天之后内存泄漏会教你做人。5. 大规模采集Scrapy 的工程化价值与边界5.1 Scrapy 到底解决了什么问题当单一请求脚本变成一套定期跑、量大、要断点续爬、出了问题要能快速定位的采集服务时Scrapy 的价值就很明显了。它不是一个单独的请求库或解析库而是一个完整的爬虫框架自带调度器、去重队列、并发下载、中间件、数据管道。一个最简单的 Scrapy 爬虫长这样import scrapy class ExampleSpider(scrapy.Spider): name example start_urls [https://example.com] def parse(self, response): yield { title: response.css(h1.title::text).get(), }然后用一行命令就能启动并发采集并把结果直接写入 JSON 或 CSVscrapy crawl example -o output.json这个简单例子背后Scrapy 已经帮你处理好了 URL 去重、请求调度、并发控制、响应解析等一堆事。你只需要写清楚怎么从响应里提取数据和下一页在哪里。5.2 什么时候该上 Scrapy什么时候别用我的判断标准可以用一句话概括脚本超过一个月要维护数据超过一万条就值得上 Scrapy。具体来说下面这些信号出现时应该认真考虑从轻量脚本迁移到 Scrapy需要采集的页面类型很多每个页面要提取几十个字段目标网站有多级翻页、详情页、搜索页链接之间有关联跳转需要断点续爬中途挂了能接着跑而不是从头再来抓取的数据要进数据库或做后续清洗中间还有很多处理步骤反过来如果只是临时抓几百条数据或者还在验证思路阶段别急着上 Scrapy。框架的好处是工程化代价是抽象层级深、调试链路长。用轻量组合快速跑通逻辑再根据实际情况决定要不要迁移是我最常用的路径。5.3 从轻量脚本迁移到 Scrapy 的路径如果你现在用 requests parsel 写好了提取逻辑迁移到 Scrapy 其实代价很低。因为 Scrapy 里的response.css(...)/response.xpath(...)和 parsel 的语法几乎一致提取函数可以说改都不用改。迁移时重点看几件事中间件User-Agent 轮换、代理 IP 管理、请求重试这些在轻量脚本里你要自己写循环Scrapy 里都有现成的中间件机制。数据管道轻量脚本最后可能是一个大 list 转 CSVScrapy 里可以拆成 pipeline每个管道负责清洗、去重、入库代码更清晰。日志与监控Scrapy 自带的日志能记录每个请求的状态、抓取量、错误率长期运行时省下的排查时间是实打实的。5.4 Scrapy 动态渲染的扩展方案2025 年的 Scrapy 也不再只是静态请求框架。社区里scrapy-playwright这个扩展把 Playwright 的能力整合进了 Scrapy你可以在 Spider 里用response yield scrapy.Request(url, meta{playwright: True})触发浏览器渲染然后继续用熟悉的 selector 语法解析动态数据。注意给 Scrapy 加渲染能力的同时也要接受并发被浏览器资源卡住的事实。渲染型爬虫的并发量远比纯请求型低架构设计时要把这两类 URL 分离开能走纯请求的别硬套渲染。6. 老坑新谈编码、超时、重试与数据落盘6.1 编码问题一份 HTML 多个说法爬虫最经典的坑没有之一。很多响应头里的Content-Type没有charset有些服务器声明了 charsetgbk 但实际返回 UTF-8有些页面在 HTML 的 meta 标签里写一套、实际内容又是另一套。最稳的处理方式是直接做检测import requests resp requests.get(https://example.com, timeout10) resp.encoding resp.apparent_encoding # 用实际内容推断编码 text resp.textapparent_encoding会基于页面内字节内容做编码推断虽然偶尔会判错但比盲目信任响应头可靠得多。如果你用了发现乱码依然存在再手动指定具体的编码比如resp.encoding gbk。6.2 超时和频率控制给请求留出退路前面提过 timeout 这个点我再展开一下。requests 和 httpx 的 timeout 参数都可以传一个元组分别指定连接超时和读取超时import httpx with httpx.Client(timeout(3.0, 10.0)) as client: # 3秒连不上就放弃10秒拿不到响应就放弃 resp client.get(https://example.com)这样分开设置之后即使目标服务器连接正常但响应很慢你的脚本也不会把所有线程都吊死在一个慢请求上。频率控制上我习惯按目标网站的容忍度来定。正规公开接口一般有明确的速率限制照着文档设置就行普通页面如果没写限制稳妥起见我会在两次请求之间加随机延迟顺便留一点抖动避免形成过于规律的请求节奏。import random import time time.sleep(random.uniform(0.5, 1.5))这个写法虽然简单但比固定的time.sleep(1)实用得多。固定间隔在日志里太规律了一眼就能看出来是机器行为。6.3 重试与日志让脚本可以无人值守网络请求失败是常态不是异常。脚本要能跑几天不挂就得把重试逻辑写进去。我常用的是一个简单的重试装饰器import random import time from functools import wraps def retry(max_times: int 3, base_delay: float 1.0): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_times): try: return func(*args, **kwargs) except Exception as e: if attempt max_times - 1: raise delay base_delay * (attempt 1) random.uniform(0, 0.5) time.sleep(delay) return None return wrapper return decorator配合日志使用重试逻辑才能发挥价值。我的习惯是每次请求成功与否都记录一下 URL、状态码、耗时跑完之后看日志就能知道哪些页面失败了、失败原因是什么不用凭空猜。6.4 数据落盘CSV、Excel、SQLite 怎么选采集的最终结果总要有个去处。我的默认选择是数据量小、以人读为主CSV或Excel。Excel 适合给业务同事直接看但要注意大文件容易卡死超十万行建议就放弃 Excel 了。结构化、有去重和增量需求SQLite。一个单文件数据库不需要装服务增删改查全都有非常适合爬虫数据的中转存储。数据量大到 SQLite 扛不住PostgreSQL / MySQL或者直接落对象存储这一般是团队级工程里的事情了。一个小建议落盘之前先做一次字段清洗。采集到的文本里经常混着多余空格、换行、HTML 标签残留在写入环节统一处理后面用数据的时候会省很多事。写在最后这几年用下来我对爬虫库选型最大的体会是库不是越多越好也不是越新越好。把 requests 用透把一种解析库练熟再在真正遇到性能瓶颈或动态页面时弄清楚渲染层和框架层的用法比追着新技术跑更有价值。我自己现在的新项目默认是 httpx parsel 起步遇到动态页面加 Playwright数据量和维护周期上来了就迁到 Scrapy基本没怎么纠结过。2025 年这个生态足够成熟关键是把选型逻辑理顺剩下的就是按需求对号入座的事。