拆解Python爬虫热门项目：批量、增量与去重核心思路

GitHub 上 Python 爬虫开源项目又双叒火了一轮。很多人看到“爬虫圈炸了”这类标题之后第一反应是收藏项目链接第二反应是找配套文档最后真正把代码跑起来的人少之又少。我最近把几类热门爬虫项目翻了一遍发现热度背后真正值得关注的并不是某个项目多了一堆 Star而是这些项目反复在解决同一批问题批量任务怎么调度、增量数据怎么识别、垂直站点怎么适配。这篇不追热点也不吹某个项目而是把这类项目背后的通用能力拆出来从环境准备、单任务跑通、批量扩展一路聊到增量爬取、框架重构和问题排查。如果你正在用 Python 做爬虫或者刚看完 GitHub 上某个高热度爬虫项目不知道从哪里下手这篇可以当作一条能照着走的路径。1. 先搞清“爬虫项目”到底在解决什么问题很多人看到“批量型爬虫”、“增量型爬虫”、“垂直型爬虫”三个词会以为这是三种并列分类其实不是。批量型描述的是任务规模增量型描述的是数据更新方式垂直型描述的是业务领域。一个真正能落地的爬虫项目经常同时具备多个特征。比如一个抓取公开新闻资讯的项目它可以每天批量抓取全部栏目同时只增量更新当天新增的文章并且只围绕新闻这个垂直领域做解析。给项目分类时不要只看名字要看它到底设计了哪些边界。看开源项目的时候我一般会先问三个问题输入是什么输出是什么失败怎么办。很多高热度项目把核心抓取流程写得很好看但一旦进入批量阶段缺少去重、重试、输出命名规范代码就会乱成一团。所以判断一个爬虫项目能不能用首要看的是任务边界而不是解析逻辑多漂亮。1.1 看项目时先看任务边界和数据格式我习惯先把项目的 README 里关于输入输出的描述抄出来然后对照代码确认。输入通常包括几种单个 URL、URL 列表、起始网站入口、接口链接、数据库表、消息队列。输出通常也有几种JSON 文件、CSV、Excel、SQLite、MySQL、对象存储。数据格式直接决定你能不能把它接进现有流程。比如你要的只是每天的增量数据但项目只支持全量抓取那你就得自己补一套增量逻辑。再比如项目把结果存成 JSON但下游要求 CSV虽然可以转换但要注意嵌套字段的展开规则。下面这张表是我看项目时常用的判断维度维度常见形态判断标准输入URL 列表 / 站点入口 / 接口 / 队列是否支持你的数据源输出JSON / CSV / 数据库是否方便接入下游调度单次任务 / 定时任务 / 队列任务是否能处理长期运行去重内存集合 / 数据库唯一键 / 文件指纹数据量增大后是否仍可靠重试无重试 / 指数退避 / 任务队列重投网络失败时任务是否会丢失频率控制无限制 / 固定延迟 / 自动限速是否容易被目标站点拒绝1.2 热门项目的能力差距集中在哪些地方同一类项目Star 数差不多的两个仓库实际用起来可能天差地别。差距一般出现在几个地方。第一站点适配层的封装程度。有些项目把某几个站点的解析规则写死在代码里换一个站点就要改一半逻辑有些项目把解析规则抽成配置换站点只改选择器。第二数据更新策略。一个能把增量逻辑做好的项目通常维护了游标或最后更新时间而不只是重跑全部页面。第三运行依赖。依赖越多越难在普通机器上部署。如果一个项目需要 Redis、Kafka、分布式调度器才能跑通而你只是想处理几千条公开数据那这项目热度再高也不适合你。我自己看项目时会先用“最小依赖路径”来测试单机、单进程、默认配置能不能跑通。能跑通再考虑扩展跑不通就看它是否明确说明需要哪些前置服务。不看说明就硬跑很容易在一开始就卡住。2. 环境准备和第一个可运行爬虫不管你是直接看开源项目还是准备自己写爬虫我都建议先准备一个干净的环境。最简单的做法是创建虚拟环境把依赖隔离到当前项目目录里避免和系统 Python 冲突。python -m venv venv source venv/bin/activate # Windows 上使用 venv\Scripts\activate pip install --upgrade pip基础依赖可以先装 requests、beautifulsoup4、lxml如果还需要处理表格数据可以加 pandas。安装时不用追求全装最新版本能用稳定版本即可。requests 负责发送 HTTP 请求BeautifulSoup 负责解析 HTMLlxml 是解析器速度比 Python 内置的 html.parser 快不少。为什么先检查 Python 版本因为很多爬虫项目采用了较新的语法比如类型注解、异步库支持。Python 3.9 到 3.12 通常都能覆盖大部分项目但如果你用的是 3.7 或更早版本部分依赖可能会装不上。先执行python --version看版本比报错后再排查更省时间。2.1 用 requests BeautifulSoup 完成第一轮请求和解析第一个可运行示例不用复杂目的只是把链路打通请求返回、解析内容、输出结果。以https://example.com这样的公开示例页面为例可以写这样一段代码import requests from bs4 import BeautifulSoup url https://example.com resp requests.get(url, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, lxml) title soup.title.get_text() print(title)这段代码包含几个值得注意的细节。timeout10很关键它让请求在指定时间内没有响应就直接抛异常而不是无限等待。raise_for_status()会把 4xx、5xx 状态码变成异常避免你拿到一个错误页面还继续解析。resp.encoding resp.apparent_encoding是用来处理编码问题的常见做法解析中文页面时经常能避免乱码。但是请求头也要注意。有些网站对没有 User-Agent 的请求直接拒绝。可以在请求里带上常见的浏览器标识headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) } resp requests.get(url, headersheaders, timeout10)这里我不会去写破解验证码或者绕过限制的代码因为正常公开数据的抓取不需要这些。遇到需要登录验证的站点应该优先看对方是否提供官方 API没有 API 就换数据源这才是更稳妥的工程选择。2.2 验证输出和错误处理跑通第一段代码后不要急着扩大范围。先验证结果标题是否输出正确、页面是否是你预期的页面、编码是否正常。更稳妥的做法是加一个简单的异常处理并把结果写入文件import requests from bs4 import BeautifulSoup url https://example.com headers {User-Agent: Mozilla/5.0} try: resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() except requests.exceptions.RequestException as e: print(f请求失败: {e}) else: soup BeautifulSoup(resp.text, lxml) title soup.title.get_text() with open(output.txt, w, encodingutf-8) as f: f.write(title) print(title)判断成功的标准不只是“没有报错”还要看文件内容是否完整标题是否存在、字符串长度是否合理、有没有出现一大堆验证码提示或者异常页面。如果输出内容明显不对第一反应不是改解析规则而是先看响应内容和状态码。3. 从单任务到批量队列、限速、输出命名单条任务跑通后自然想处理一批 URL。最直接的写法是 for 循环但直接循环有几个问题没有失败重试、没有时间间隔、没有状态记录。如果中间有一条 URL 超时整个任务直接中断前面抓到的结果可能只留在内存里一旦程序退出就丢了。一个简单的改进是维护一个待抓取列表循环处理并在每次请求之间加合理延迟。延迟的作用是降低对目标服务器的压力属于正常访问礼貌。示例import time import requests urls [ https://example.com/1, https://example.com/2, https://example.com/3, ] for index, url in enumerate(urls, start1): try: resp requests.get(url, timeout10) resp.raise_for_status() print(index, url, len(resp.text)) except requests.exceptions.RequestException as e: print(index, url, 失败, e) time.sleep(1)这里sleep(1)是通用做法具体间隔要根据目标网站的承受能力和数据量来定。不是说间隔越小越好也不是越大越好。如果你只是爬几条示例页面甚至可以不延迟但如果你要跑几千条就要把延迟和失败重试一起考虑进去。3.1 怎样设计输出文件避免任务覆盖和丢失批量任务最容易踩的坑不是抓不到数据而是输出结果被覆盖。很多人习惯把一个结果文件命名为 data.csv第二次运行直接覆盖第一次数据。如果第一次数据还没验证那就只能重新跑。我建议一开始就按“日期/源ID/结果文件”的方式组织输出目录data/ tasks/ 2025-01-15/ url_001.html url_002.html summary.csv文件名里加日期或 URL 的哈希值可以避免重复覆盖。同时在每条任务完成后把状态写入一个单独的日志文件记录 URL、时间、状态、输出文件名。这样即使程序中途退出你也可以从日志里知道哪些成功、哪些失败、哪些未执行。3.2 先跑小样再放大量任务这是我最想强调的一点不要一上来就开最大并发或者一次性把几千条 URL 全部跑完。先挑 5 条数据验证链路再挑 50 条验证稳定性最后再跑全量。全量跑的时候也不要一直盯着屏幕要看日志和资源占用。判断一次批量任务是否正常我一般看四个指标成功比例如果前 50 条里面有 10 条失败说明某些 URL 格式或目标站点有问题。单条耗时单条请求平均耗时是否在预期范围内。如果突然变慢可能是请求过于频繁被服务端限流。内存占用如果内存持续上涨可能是在解析过程中保存了太多上下文。磁盘占用日志和输出文件是否增长正常有没有出现单个文件无限增大。4. 增量爬取、去重和断点续跑的核心思路增量爬取是很多 GitHub 热门项目的卖点但不少人误以为只要有定时器、每天跑一次就算增量。真正的增量爬取核心在于记录状态你能识别出哪些数据是新的哪些是已经处理过的哪些发生了变化。常见做法是记录数据源里最后更新的时间戳或主键 ID。每次抓取前先查询当前序列或时间位置然后只获取大于该位置的数据。如果数据源分页还要记录当前抓到哪一页。这里的关键难点在于时间戳可能有时区问题分页顺序可能不稳定所以最好用稳定的业务 ID 或唯一字段作为游标而不是完全依赖时间。4.1 常见去重方案内存集合、数据库、文件指纹去重最常见的三种方案各有适用边界。内存集合快但只能在单进程、单次运行内有效数据库唯一索引可靠但依赖数据库环境文件指纹适合离线数据去重但要考虑文件读取成本。如果你只是学习可以用最简单的内存集合seen set() for url in urls: if url in seen: continue seen.add(url) # 执行抓取但一旦任务量变大比如几百万条 URL内存集合可能占用过大。这时候可以用 Redis 的 SET 或数据库唯一索引。关键不是哪种技术更高级而是你要清楚去重范围是单次运行去重还是多次运行之间也要去重。如果是后者必须把已处理标识持久化。4.2 断点续跑到底需要保存哪些信息断点续跑不是简单保存“最后一条 URL”而是要保存足够多的状态信息让程序重启后可以准确恢复。我建议至少保存四类信息已成功的条目、失败的条目及失败原因、当前游标位置、输出文件的写入位置。用 SQLite 保存比较方便不需要额外启动数据库服务。示例表结构可以这样设计CREATE TABLE task_state ( id INTEGER PRIMARY KEY, url TEXT UNIQUE, status TEXT, retry_count INTEGER DEFAULT 0, output_file TEXT, updated_at TEXT );每次处理完一条 URL就更新对应记录。程序启动时先读取上次状态跳过 status 为 success 的 URL对失败超过一定次数的 URL 直接标记为 failed不再重试。这样即使运行到一半断网重启后也能接着跑。5. 用开源框架 Scrapy 重新组织爬虫当你的爬虫从几十条 URL 扩展到几万条自己用 requests 循环写的代码会越来越难维护。这个时候可以考虑使用 Scrapy。Scrapy 是 Python 生态里比较成熟的爬虫框架提供了请求调度、并发控制、去重、中间件、数据管道等一整套机制。安装和创建项目的命令很简单pip install scrapy scrapy startproject demo_spider项目结构里spiders 目录存放爬虫逻辑items.py 定义数据字段pipelines.py 负责数据输出和清洗settings.py 配置并发、延迟、下载中间件等。第一次接触时不需要全部弄懂先理解一个完整流程Spider 发出请求收到响应后解析再把结果交给 Pipeline。5.1 如何把已有 requests 爬虫迁移到 Scrapy迁移时不需要重写所有逻辑。requests 里的requests.get对应 Scrapy 里的scrapy.RequestBeautifulSoup 的解析逻辑可以替换成 Scrapy 自带的 Selector也可以继续用 BeautifulSoup。Scrapy 的 Response 对象有css和xpath方法比较常用。一个极简 Spider 示例import scrapy class ExampleSpider(scrapy.Spider): name example start_urls [https://example.com] def parse(self, response): yield { title: response.css(title::text).get(), url: response.url, }这段代码看起来很简单但背后已经包含请求调度、响应处理和去重。比 requests 手动循环省去了不少样板代码。迁移时要注意Scrapy 默认的请求去重是针对 URL 的如果你需要更复杂的去重逻辑可以在 Request 的 meta 里传入信息或者重写 dupefilter。5.2 调度、并发和限流的参数边界Scrapy 的 settings.py 里有几个参数对稳定性影响很大CONCURRENT_REQUESTS表示并发请求数DOWNLOAD_DELAY表示请求间隔AUTOTHROTTLE_ENABLED可以开启自动限速。新手阶段建议保持保守配置参数学习环境建议值批量生产环境参考值CONCURRENT_REQUESTS8 或更低根据目标站点承载能力调整DOWNLOAD_DELAY1 秒0.5 到 3 秒之间AUTOTHROTTLE_ENABLEDFalseTrue可配合 DOWNLOAD_DELAYRETRY_TIMES23 到 5低配机器上不要一味调高并发。并发升高会同时拉高内存和 CPU 占用如果目标站点响应慢阻塞队列还会越积越多。我一般先用默认配置跑通再逐步调高观察失败率和耗时变化。没有哪个参数是“越大越好”。6. 排查链路从报错、卡住到输出异常爬虫出问题的时候第一件事不是改参数而是看日志。先确认是网络层失败、解析层失败还是数据层失败。比如日志里全是Timeout说明目标站点响应慢或网络不通如果是404说明 URL 拼接或列表页有问题如果是解析结果为空说明页面结构可能变了或者请求被跳转到了登录页。我见过很多新手一遇到失败就怀疑工具不行实际原因只是缺失 User-Agent或者输出目录没有写权限。日志能帮你快速缩小排查范围所以从一开始就要养成打印日志的习惯。6.1 输入格式、编码、路径和权限的优先级如果“看不出问题”但结果不对建议按这个顺序排查输入 URL编码是否正常有没有多余空格或特殊字符。响应内容状态码、编码、页面标题是否和预期一致。解析规则选择器是否匹配页面结构是否换过。输出路径目录是否存在是否有写权限。依赖版本lxml、parsel、Scrapy 等库版本是否兼容你的 Python。很多“功能不支持”的报错最后查出来都是文件路径里有中文或空格或者输出目录不存在。因为有人喜欢用终端直接重定向输出结果文件生成在没有权限的目录里程序不报错但数据就是写不进去。6.2 资源占用和稳定性判断爬虫跑久了最容易出现的问题不是功能报错而是资源占用持续上升。如果你看到 Python 进程内存从 200MB 涨到 2GB先不要觉得是内存泄漏也许是你的代码在处理大量响应时保存了太多对象。解决办法是减少保存原始响应解析完立刻把不需要的变量释放或者用生成器而不是一次把全部数据加载进内存。稳定性判断不能只看“能不能跑起来”。我建议每次运行后记录三条数据成功数、失败数、总耗时。连续跑三到五次如果失败率稳定在可接受范围才说明这个任务基本稳定。7. 爬虫工具和学习文档怎么用才有效很多人在 GitHub 上收藏了一堆 Python 爬虫开源项目也下载了学习文档但进步很慢。原因是把这些资料当收藏品而不是当练习材料。文档的价值只有在代码运行起来后才能体现。每看一个项目我建议完成三个动作跑通官方示例、改一个数据源、加一个字段或管道。能完成这三步你才算真正吸收了项目。工具清单方面这几种可以优先学工具/库用途学习重点requestsHTTP 请求超时、请求头、会话BeautifulSoup / parselHTML 解析选择器、提取规则Scrapy爬虫框架调度、管道、中间件Playwright需要浏览器渲染的页面等待、截图、页面交互SQLite本地存储表设计、增量去重Playwright 属于“浏览器自动化”场景不是破解限制而是处理正常前端渲染的公开页面。7.1 合规边界和常见误区这里要特别提一下。爬虫是技术工具能跑通不代表可以随便用。合规的爬虫开发通常有几个前提只爬取公开数据不采集个人敏感信息遵守目标网站的 robots 协议和访问频率不把抓取到的数据用于侵权、欺诈等非法场景如果目标网站提供官方 API优先使用 API而不是绕过页面限制。很多热词里提到的“爬虫软件”“爬虫工具”本质上都只是自动化获取公开信息的手段。真正值得关注的不是“能不能抓”而是“该不该抓”。我写代码时会把频率控制、数据范围、失效反馈写进项目里既是对目标网站负责也是对自己的任务稳定性负责。7.2 从工具到工程化的后续方向当一个爬虫项目已经在本地稳定运行下一步可以往工程化方向走。先把配置从代码里拆出来比如 URL 列表、请求间隔、输出目录都放到单独的配置文件中。然后加日志系统把每次运行结果写到文件或数据库。如果任务多起来可以看看任务队列和定时调度比如用操作系统的 cron 定时任务或者更重的调度平台。不是所有项目都需要一步到位。你只需要先回答一个问题你手里的任务是要跑一次还是要每天跑如果要每天跑去重、增量、失败重试、日志监控就都变成了刚需。这些能力也正是那些在 GitHub 上持续获得关注的开源爬虫项目真正值钱的地方。个人建议先把单任务跑稳再考虑批量和接口。一个高热度项目到底适不适合你不看 Star 数不看标题多火爆而要看它能不能在你的普通机器上稳定复制。那些真正有用的项目通常文档清楚、边界明确、不依赖一堆重型服务。你带着任务去审视它们而不是反过来被项目带着走。先把 requests 和 Scrapy 的基础链路练熟再回头看那些开源项目你会突然发现原来它们真正解决的就是状态记录、队列调度和输出管理这些事。