1. 与手写Requests脚本相比Scrapy究竟解决了什么问题1.1 手写爬虫的四个痛点我最早写爬虫的时候和绝大多数人一样用Requests加BeautifulSoup。当时抓一个某图书网站的数据代码大致长这样一个函数发请求一个函数解析HTML一个函数存CSV再写个for循环把所有页面跑一遍。功能是能跑但越写越觉得别扭。第一个痛点是并发全靠自己写。真要抓几千个页面单线程跑下去能等到天荒地老你得自己引入ThreadPoolExecutor还要处理线程安全、结果收集、异常隔离。第二个痛点是重试和异常处理散落在每一处总有照顾不到的请求。第三个痛点是下载和解析耦合在一起今天页面结构变了改解析逻辑时不小心会动到请求逻辑很容易改出问题。第四个痛点是没有统一的去重机制同一个URL可能被反复请求浪费带宽也容易被目标站点拉黑。如果只写一两个小脚本这些问题都勉强可以接受。但一旦你开始做“批量抓取”“定期更新”“多站点采集”维护成本就会指数级上升。这也是我后来转向Scrapy的直接原因——不是Requests不够好而是我需要一个把“下载、解析、存储、去重、重试、调度”全部拆开管理的框架。1.2 Scrapy的整体设计思路Scrapy不是“一个发请求的库”它是一套爬虫工程框架。它默认规定的思路是你把“如何解析页面”和“抓到数据后如何处理”写清楚而“怎么下载、什么时候下载、怎么调度、怎么重试、怎么去重”这些事全部交给框架的核心引擎统一处理。这种思路最直接的收益是关注点分离。你可以只盯着Spider里面写CSS选择器不用担心某个请求超时了怎么办——那是Downloader Middleware的事你也不用纠结数据是存成CSV还是写进数据库——那是Item Pipeline的事。每一层只干一件事出了问题排查范围非常清楚。以我个人的经验一个刚接触Scrapy的新手最需要改变的心态就是“我要写爬虫”变成“我在用一个爬虫框架按它的规则填内容”。这个框架给你准备了五个核心组件Spider、Scheduler、Downloader、Pipeline、Engine。理解这套架构比记住任何API都重要。2. Scrapy核心架构五大组件如何各司其职2.1 Spider你的业务逻辑入口Spider是所有Scrapy项目里最“热闹”的地方。它是你编写代码的主要区域决定了两件事抓哪些URL、从响应里提取什么信息。一个最简单的Spider长这样import scrapy class BooksSpider(scrapy.Spider): name books start_urls [http://books.toscrape.com/] def parse(self, response): for book in response.css(article.product_pod): yield { title: book.css(h3 a::attr(title)).get(), price: book.css(.price_color::text).get() } next_page response.css(.next a::attr(href)).get() if next_page: yield response.follow(next_page, callbackself.parse)这段代码里有两个核心机制值得说。第一是yieldparse方法是一个生成器yield出来的每一项可以是一本字典也可以是新的Request。主引擎拿到yield出来的字典会交给Pipeline处理拿到Request则重新进入调度队列。正是这个设计让Scrapy不需要像手写程序一样手动排队。第二是response.follow自动拼接相对URL省去你手写urljoin的麻烦。爬取翻页就是这么一层层“跟随”下去的。很多初学者不理解“parse为什么又被调用一次”——其实就是这个回调函数被当作“每一个页面下载完成后的处理函数”翻页之后的新页面依然交给同一个函数处理。2.2 Scheduler与Downloader调度与下载的配合Scheduler是Scrapy的调度器职责是维护一个待抓取的请求队列。默认情况下它是基于内存的FIFO队列配合集合做去重。Downloader才是真正“发HTTP请求”的组件。这两者的配合逻辑是Engine把一个Request交给Scheduler排队Scheduler按顺序吐出一个RequestEngine再交给Downloader下载下载完的Response又送回Engine由Engine找到对应的Spider回调函数执行。这个设计的好处显而易见下载速度和解析速度彻底解耦。即使某个页面解析很慢Downloader也不会傻等着它可以继续下载下一批请求。配合CONCURRENT_REQUESTS设置Scrapy可以同时维持几十个并发连接而你的Spider代码完全不用关心这些并发细节。对比手写Requests加线程池的方案Scrapy相当于自带了一个生产消费模型而且是无缝衔接的。我见过不少项目手写方案一到并发调大就出现数据缺失、请求超时、内存暴涨各种问题而相同任务量Scrapy的稳定性明显好很多。2.3 Pipeline与Middleware数据的下游处理如果说Spider是“生产数据”的地方Pipeline就是“处理数据”的地方。数据从Spider里面yield出来按顺序经过一组配置好的Pipeline组件每个组件对数据做一项操作——清洗字段、去重、校验、存数据库、存文件。Pipeline最常见的应用是存储。举个实际例子抓某招聘网站的职位数据我想同时保留两份副本一份CSV方便人工查看一份MongoDB方便程序查询那就写两个Pipeline类在settings.py里按顺序配置即可ITEM_PIPELINES { myproject.pipelines.CsvPipeline: 300, myproject.pipelines.MongoPipeline: 400, }后面的数字是执行顺序数字小的先执行。这个约定初看反直觉遇到多个Pipeline需要明确顺序时就会觉得设计得很合理。Middleware则像个“拦截层”。Downloader Middleware在请求发出前和响应返回后各插一脚能做的事情包括修改请求头、设置代理、处理重试、篡改请求体。Spider Middleware则夹在Engine和Spider之间用来处理Spider的输入输出最常见的场景是捕获Spider抛出的异常。2.4 一次请求的完整生命周期把五个组件串起来看一次完整请求的路径大概是Spider里yield一个Request → Engine接收后交给Scheduler → Scheduler去重后排队 → Scheduler按序返回给Engine → Engine交给Downloader → Downloader经过请求Middleware发送HTTP请求 → 收到响应后经过响应Middleware → Engine拿到Response → Engine找到该Request对应的回调函数交给Spider处理 → Spider解析后yield Item或新的Request → Item则流向PipelineRequest则重新进入调度队列。这个生命周期我建议每个想用好Scrapy的人自己对着源码梳理一遍。你不一定需要改框架内部逻辑但理解了这条链路之后以后遇到任何诡异问题比如为什么请求被吞了、为什么Pipeline没执行、为什么Middleware没生效你至少知道该去哪一环排查。3. 从零搭建第一个Scrapy爬虫完整实操流程3.1 环境初始化与常见错误安装Scrapy非常简单一条命令搞定pip install scrapy如果遇到依赖安装失败通常是在Windows环境下缺少某个编译工具建议优先安装对应版本的二进制依赖包或者直接使用Anaconda环境安装conda install scrapy创建项目的命令是scrapy startproject myspider这会在当前目录生成一个完整的工程骨架结构如下myspider/ scrapy.cfg myspider/ __init__.py items.py middlewares.py pipelines.py settings.py spiders/ __init__.py很多新手把这步理解成“建了一个文件夹”实际上脚手架生成了一套完整约定。settings.py里写着所有可调参数spiders目录放你的爬虫代码pipelines.py和middlewares.py分别对应数据管道和中间件。区分这些目录的用途是使用Scrapy的第一个里程碑。3.2 Item与Spider的协同写法Item是Scrapy里定义数据结构的地方。你可以把它理解成一张“字段表”写明你准备提取哪些数据。定义好之后Spider和Pipeline都围绕Item协作避免字段名满天飞import scrapy class BookItem(scrapy.Item): title scrapy.Field() price scrapy.Field() rating scrapy.Field()有人会觉得多此一举直接yield一个字典不就行了在小项目里确实够用但一旦字段多起来或者同一个爬虫被多个人维护Item的价值立刻体现出来——它让你一眼看出这条数据的“schema”。而且在Pipeline里做字段校验也更方便可以只处理特定Item或者检测必填字段缺失就丢给日志。写Spider的时候我习惯分成三步先写start_requests或start_urls再写parse主逻辑最后把需要翻页或详情页请求的URL单独抽成方法。不要把所有逻辑塞进一个parse后面维护会非常痛苦。3.3 运行、调试与结果输出开发阶段最常用的运行方式有两个scrapy crawl books -o books.json这条命令会把所有Pipeline产出的Item直接导出到books.json文件。另一个是Shell调试模式scrapy shell http://books.toscrape.com/Shell模式可以说是提高效率的利器。写CSS选择器选到没把握时先在Shell里试一遍确认无误再写回Spider能省掉大量的“改代码-重跑-看日志”循环。JSON导出的编码问题是个经典坑默认输出的中文是Unicode转义符看起来非常不直观。加一句配置就能解决FEED_EXPORT_ENCODING utf-8如果是抓下来的字段带有前后空格、HTML标签这些脏数据不要试图在Spider里全部处理干净那是Pipeline的职责。下面这点我要强调一下Spider负责“提取”Pipeline负责“清洗”两者不要混在一起。3.4 settings.py里我从第一天起就改的几个参数先说配置前的默认状态Scrapy出于对目标站点的尊重默认不开启并发下载延迟是0默认请求头里U-A是Scrapy的版本标识很容易被目标站点识别。我建议从一开始就修改以下四项USER_AGENT Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ROBOTSTXT_OBEY True DOWNLOAD_DELAY 1.5 CONCURRENT_REQUESTS 8USER_AGENT伪装成常规浏览器是绝大多数站点最基本的要求ROBOTSTXT_OBEY打开后Scrapy会先检查目标站的robots.txt是否允许抓取指定路径这是合规的第一道门槛DOWNLOAD_DELAY是请求间隔越大越安全CONCURRENT_REQUESTS是并发数。这四个参数是“安全起步”的基本配置。4. 数据落地与去重机制Pipeline和过滤器实战解析4.1 Item Pipeline的典型应用Pipeline能做的事情远比“存数据库”丰富得多。我把日常开发中最常用的几种场景列出来供你对照自己的需求场景Pipeline动作示例实现思路字段清洗去除空格、替换非法字符process_item里做strip操作数据校验必填字段缺失则丢弃检查Item中字段为None则raise DropItem去重相同数据不重复入库用集合记录已见过的唯一键多端存储同时写CSV和数据库配置两条Pipeline按顺序执行数据转换字符串数字转float在Pipeline里统一处理分发通知异常数据推送告警捕获异常后打日志发消息拿数据校验举例一个典型的“丢弃脏数据”Pipeline长这样from scrapy.exceptions import DropItem class RequiredFieldsPipeline: def process_item(self, item, spider): if not item.get(title): raise DropItem(fMissing title in {item}) return item被raise DropItem的Item不会进入后续Pipeline这个机制配合日志可以非常方便地统计抓取质量。4.2 URL去重与重复数据问题Scrapy默认自带一个去重机制基于Request的指纹指纹由请求方法与URL等参数计算。同一个URL只会被下载一次。但实际项目中还有两类常见的重复问题内容重复但URL不同比如带各种追踪参数的URL、同一商品的不同入口链接翻页循环比如下一页链接把自己拼到无限长。针对内容重复我会在Pipeline里用“唯一键集合”再做一道去重。更稳妥的做法是引入布隆过滤器在请求层面就把相似参数归一化。针对翻页循环需要你在Spider里仔细控制终止条件不要只依赖“next_page为空就停”某些站点会把当前页URL伪装成下一页导致死循环。4.3 一个图书网站抓取的完整Pipeline配置我以前写过一个抓图书数据的爬虫Pipeline的配置顺序是这样的先字段清洗再必填校验最后写MongoDB。清洗的逻辑简单但很实用——把价格从“£51.77”这种文本转成51.77这个浮点数把评分从“Three”转成3。class CleanPipeline: def process_item(self, item, spider): price item.get(price, 0) item[price] float(price.replace(£, ).strip()) if item.get(rating): rating_map {One: 1, Two: 2, Three: 3, Four: 4, Five: 5} item[rating] rating_map.get(item[rating], 0) return item在配置顺序上清洗Pipeline的数值要比存储Pipeline小这样才能保证入库前数据已经是干净状态。数值间隔我习惯留100方便以后在中间插入新的Pipeline。这里有个值得一提的细节Scrapy的Pipeline机制默认是“链式传递”。每个Pipeline的process_item方法拿到上一步返回的item处理完再传给下一步。如果你在流程中间return了None这条数据就断在这儿了。所有离开爬虫的数据都必须以Item或字典的形式走完整条链路。5. 反爬应对策略与合规操作边界5.1 常见反爬机制和针对性处理思路爬虫写得好不好一半体现在应对反爬的能力上。常见机制和常规处理思路大致如下反爬手段表现方式常规应对策略User-Agent检查拒绝非浏览器请求随机切换UA池请求频率限制出现验证码或封IP调大DOWNLOAD_DELAYCookie校验未登录态直接跳转登录后保持Cookie页面动态渲染数据由JS加载换用渲染工具配合WebDriver检测检测自动化浏览特征修改指纹参数关于随机UA可以自己维护一个列表在Downloader Middleware里随机选择。复杂一点可以用现成的第三方UA库但核心逻辑都一样。某个站点如果对访问频率极其敏感设置UA的作用就有限了真正起作用的往往是请求间隔和代理池。5.2 请求头、Cookie与代理的配置请求头里面除了User-Agent还有Referer、Accept-Language等。很多站点的后端会校验Referer是否来自自己的页面这种情况我会在爬虫里动态补上模拟真实的浏览路径。Cookie方面最简单的方案是打开浏览器里的开发者工具复制当前的Cookie头放到Request里直接带上。但Cookie会过期长期运行需要换成登录接口动态获取。我常用的做法是把登录和爬取分开先用Requests完成登录拿到Cookie再通过Middleware注入到每个请求里。5.3 合规边界别踩线这一段我想多说几句。爬虫虽然技术上有很强的“对抗性”但使用边界必须清晰。我给自己的项目定了几条硬规矩遵守robots.txt的声明不爬明确禁止的路径请求频率保持在人类浏览水平不加压公开数据用于学习研究不涉及隐私与版权内容不对站点造成可用性损害这三条原则不一定能帮你“抓到更多数据”但能保证你的项目在灰色地带里站得住脚。技术能力再强也别把爬虫做成对目标站点的攻击性工具。个人学习抓一点公开数据没问题但大规模采集生产数据前先想清楚用途是否合法合规。6. 性能调优与生产环境部署要点6.1 并发量与请求延迟的动态平衡Scrapy性能调优的核心就一句话在目标站点能承受的前提下最大化吞吐量。实践中需要根据目标站点的反应动态调整两个参数CONCURRENT_REQUESTS和DOWNLOAD_DELAY。我曾经抓过某小型BBS用Settings.py里默认的并发就触发了封禁策略降到每秒一个请求才恢复正常。后来总结的经验是遇到封禁不要急着加代理先看自己的请求频率是否人道。毕竟国内很多站点防护规则很简单——单IP频率超过阈值直接拉黑。如果目标站点响应速度很稳定还可以把DOWNLOAD_DELAY设为0只保留一小段随机延迟配合较大的CONCURRENT_REQUESTS通常能获得不错的吞吐量。比较稳妥的起步参数区间是延迟1到2秒并发8到16。在此基础上逐步下调延迟直到出现异常再回退一档。6.2 常见坑与排查思路下面这些坑我几乎在带新人时都会再踩一遍先列出来帮大家避雷DEBUG日志里能看到Response但parse不执行——多半是回调函数写错名字或请求被回调函数返回的Item打断。抓下来的数据全部重复而且越抓越多——去重键没设计好可能是URL带了变化的时间戳参数。Pipeline一个都没执行——检查settings.py里ITEM_PIPELINES的配置是否生效有没有拼错类路径。日志提示“Filtered offsite”——Scrapy默认的安全机制防止拿A站点的链接去B站点下载检查Spider的allowed_domains。scrapy crawl后一个请求都不发——先看robots.txt是否设为False再看start_urls是否拼错。排查的顺序我建议遵循先看日志级别Scrapy的INFO和DEBUG日志信息量很大再看目标站点是否有响应异常最后才查代码逻辑。很多时候是配置问题而非代码问题。6.3 从单机到分布式扩展思路单机Scrapy跑批量数据通常够用。但如果数据量极大就需要扩展。极简方案是借助第三方调度器把Scheduler替换成基于Redis的共享队列让多台机器共用同一个待抓取集合。Spider代码改动很小主要在settings.py里换掉调度器配置。另一种轻量做法是把Requests直接写成独立任务用消息队列分发给多台机器每台机器跑一个独立的Scrapy爬虫。但这样去重会分散需要额外统一管理抓取指纹。我个人的建议是先确认单机瓶颈在哪再做分布式。如果瓶颈在网络延迟与目标站点限制分布式收效甚微如果瓶颈在解析密集型任务与本地存储分布式才有意义。分布式带来的管理复杂度提升不是一星半点为一个千级页面项目上分布式纯属给自己找麻烦。写在最后的一些经验搜了一圈资料写这篇文章顺手把这几年的笔记也翻了翻。有些经验我觉得值得单独拿出来说Scrapy的易用性有一个“迷惑期”——你得写出第一个能稳定跑完的爬虫才真正入门。别再纠结框架本身遇到问题先直接看Stack Overflow再不行就查文档文档里的示例质量很高。最有效的学习路径是拿一个真实站点从头到尾写一个完整的爬虫过程中把Pipeline、Middleware、Shell调试都过一遍比刷什么教程都管用。还有一点补充给正在做采集项目的读者数据落库之前一定要留一份原始响应。我习惯在Pipeline里把每个页面的原始HTML存一份方便后续字段遗漏时重新解析省得重新爬一遍。这个小习惯在长期项目里救过我很多次。最后再分享一个小技巧在settings.py里加一个自定义的LOG_LEVEL配置主流程用INFO业务代码里用DEBUG记录关键数据流向比如“正在处理第N个详情页”。跑批任务的时候把日志保存到文件出错后不用重新调试直接对着日志定位现场。Scrapy的日志系统扩展性很强值得花时间建立自己的日志习惯。抓取这件事技术本身不复杂做精的功夫都在细节里。希望这篇文章对你有所帮助。
1. 与手写Requests脚本相比Scrapy究竟解决了什么问题1.1 手写爬虫的四个痛点我最早写爬虫的时候和绝大多数人一样用Requests加BeautifulSoup。当时抓一个某图书网站的数据代码大致长这样一个函数发请求一个函数解析HTML一个函数存CSV再写个for循环把所有页面跑一遍。功能是能跑但越写越觉得别扭。第一个痛点是并发全靠自己写。真要抓几千个页面单线程跑下去能等到天荒地老你得自己引入ThreadPoolExecutor还要处理线程安全、结果收集、异常隔离。第二个痛点是重试和异常处理散落在每一处总有照顾不到的请求。第三个痛点是下载和解析耦合在一起今天页面结构变了改解析逻辑时不小心会动到请求逻辑很容易改出问题。第四个痛点是没有统一的去重机制同一个URL可能被反复请求浪费带宽也容易被目标站点拉黑。如果只写一两个小脚本这些问题都勉强可以接受。但一旦你开始做“批量抓取”“定期更新”“多站点采集”维护成本就会指数级上升。这也是我后来转向Scrapy的直接原因——不是Requests不够好而是我需要一个把“下载、解析、存储、去重、重试、调度”全部拆开管理的框架。1.2 Scrapy的整体设计思路Scrapy不是“一个发请求的库”它是一套爬虫工程框架。它默认规定的思路是你把“如何解析页面”和“抓到数据后如何处理”写清楚而“怎么下载、什么时候下载、怎么调度、怎么重试、怎么去重”这些事全部交给框架的核心引擎统一处理。这种思路最直接的收益是关注点分离。你可以只盯着Spider里面写CSS选择器不用担心某个请求超时了怎么办——那是Downloader Middleware的事你也不用纠结数据是存成CSV还是写进数据库——那是Item Pipeline的事。每一层只干一件事出了问题排查范围非常清楚。以我个人的经验一个刚接触Scrapy的新手最需要改变的心态就是“我要写爬虫”变成“我在用一个爬虫框架按它的规则填内容”。这个框架给你准备了五个核心组件Spider、Scheduler、Downloader、Pipeline、Engine。理解这套架构比记住任何API都重要。2. Scrapy核心架构五大组件如何各司其职2.1 Spider你的业务逻辑入口Spider是所有Scrapy项目里最“热闹”的地方。它是你编写代码的主要区域决定了两件事抓哪些URL、从响应里提取什么信息。一个最简单的Spider长这样import scrapy class BooksSpider(scrapy.Spider): name books start_urls [http://books.toscrape.com/] def parse(self, response): for book in response.css(article.product_pod): yield { title: book.css(h3 a::attr(title)).get(), price: book.css(.price_color::text).get() } next_page response.css(.next a::attr(href)).get() if next_page: yield response.follow(next_page, callbackself.parse)这段代码里有两个核心机制值得说。第一是yieldparse方法是一个生成器yield出来的每一项可以是一本字典也可以是新的Request。主引擎拿到yield出来的字典会交给Pipeline处理拿到Request则重新进入调度队列。正是这个设计让Scrapy不需要像手写程序一样手动排队。第二是response.follow自动拼接相对URL省去你手写urljoin的麻烦。爬取翻页就是这么一层层“跟随”下去的。很多初学者不理解“parse为什么又被调用一次”——其实就是这个回调函数被当作“每一个页面下载完成后的处理函数”翻页之后的新页面依然交给同一个函数处理。2.2 Scheduler与Downloader调度与下载的配合Scheduler是Scrapy的调度器职责是维护一个待抓取的请求队列。默认情况下它是基于内存的FIFO队列配合集合做去重。Downloader才是真正“发HTTP请求”的组件。这两者的配合逻辑是Engine把一个Request交给Scheduler排队Scheduler按顺序吐出一个RequestEngine再交给Downloader下载下载完的Response又送回Engine由Engine找到对应的Spider回调函数执行。这个设计的好处显而易见下载速度和解析速度彻底解耦。即使某个页面解析很慢Downloader也不会傻等着它可以继续下载下一批请求。配合CONCURRENT_REQUESTS设置Scrapy可以同时维持几十个并发连接而你的Spider代码完全不用关心这些并发细节。对比手写Requests加线程池的方案Scrapy相当于自带了一个生产消费模型而且是无缝衔接的。我见过不少项目手写方案一到并发调大就出现数据缺失、请求超时、内存暴涨各种问题而相同任务量Scrapy的稳定性明显好很多。2.3 Pipeline与Middleware数据的下游处理如果说Spider是“生产数据”的地方Pipeline就是“处理数据”的地方。数据从Spider里面yield出来按顺序经过一组配置好的Pipeline组件每个组件对数据做一项操作——清洗字段、去重、校验、存数据库、存文件。Pipeline最常见的应用是存储。举个实际例子抓某招聘网站的职位数据我想同时保留两份副本一份CSV方便人工查看一份MongoDB方便程序查询那就写两个Pipeline类在settings.py里按顺序配置即可ITEM_PIPELINES { myproject.pipelines.CsvPipeline: 300, myproject.pipelines.MongoPipeline: 400, }后面的数字是执行顺序数字小的先执行。这个约定初看反直觉遇到多个Pipeline需要明确顺序时就会觉得设计得很合理。Middleware则像个“拦截层”。Downloader Middleware在请求发出前和响应返回后各插一脚能做的事情包括修改请求头、设置代理、处理重试、篡改请求体。Spider Middleware则夹在Engine和Spider之间用来处理Spider的输入输出最常见的场景是捕获Spider抛出的异常。2.4 一次请求的完整生命周期把五个组件串起来看一次完整请求的路径大概是Spider里yield一个Request → Engine接收后交给Scheduler → Scheduler去重后排队 → Scheduler按序返回给Engine → Engine交给Downloader → Downloader经过请求Middleware发送HTTP请求 → 收到响应后经过响应Middleware → Engine拿到Response → Engine找到该Request对应的回调函数交给Spider处理 → Spider解析后yield Item或新的Request → Item则流向PipelineRequest则重新进入调度队列。这个生命周期我建议每个想用好Scrapy的人自己对着源码梳理一遍。你不一定需要改框架内部逻辑但理解了这条链路之后以后遇到任何诡异问题比如为什么请求被吞了、为什么Pipeline没执行、为什么Middleware没生效你至少知道该去哪一环排查。3. 从零搭建第一个Scrapy爬虫完整实操流程3.1 环境初始化与常见错误安装Scrapy非常简单一条命令搞定pip install scrapy如果遇到依赖安装失败通常是在Windows环境下缺少某个编译工具建议优先安装对应版本的二进制依赖包或者直接使用Anaconda环境安装conda install scrapy创建项目的命令是scrapy startproject myspider这会在当前目录生成一个完整的工程骨架结构如下myspider/ scrapy.cfg myspider/ __init__.py items.py middlewares.py pipelines.py settings.py spiders/ __init__.py很多新手把这步理解成“建了一个文件夹”实际上脚手架生成了一套完整约定。settings.py里写着所有可调参数spiders目录放你的爬虫代码pipelines.py和middlewares.py分别对应数据管道和中间件。区分这些目录的用途是使用Scrapy的第一个里程碑。3.2 Item与Spider的协同写法Item是Scrapy里定义数据结构的地方。你可以把它理解成一张“字段表”写明你准备提取哪些数据。定义好之后Spider和Pipeline都围绕Item协作避免字段名满天飞import scrapy class BookItem(scrapy.Item): title scrapy.Field() price scrapy.Field() rating scrapy.Field()有人会觉得多此一举直接yield一个字典不就行了在小项目里确实够用但一旦字段多起来或者同一个爬虫被多个人维护Item的价值立刻体现出来——它让你一眼看出这条数据的“schema”。而且在Pipeline里做字段校验也更方便可以只处理特定Item或者检测必填字段缺失就丢给日志。写Spider的时候我习惯分成三步先写start_requests或start_urls再写parse主逻辑最后把需要翻页或详情页请求的URL单独抽成方法。不要把所有逻辑塞进一个parse后面维护会非常痛苦。3.3 运行、调试与结果输出开发阶段最常用的运行方式有两个scrapy crawl books -o books.json这条命令会把所有Pipeline产出的Item直接导出到books.json文件。另一个是Shell调试模式scrapy shell http://books.toscrape.com/Shell模式可以说是提高效率的利器。写CSS选择器选到没把握时先在Shell里试一遍确认无误再写回Spider能省掉大量的“改代码-重跑-看日志”循环。JSON导出的编码问题是个经典坑默认输出的中文是Unicode转义符看起来非常不直观。加一句配置就能解决FEED_EXPORT_ENCODING utf-8如果是抓下来的字段带有前后空格、HTML标签这些脏数据不要试图在Spider里全部处理干净那是Pipeline的职责。下面这点我要强调一下Spider负责“提取”Pipeline负责“清洗”两者不要混在一起。3.4 settings.py里我从第一天起就改的几个参数先说配置前的默认状态Scrapy出于对目标站点的尊重默认不开启并发下载延迟是0默认请求头里U-A是Scrapy的版本标识很容易被目标站点识别。我建议从一开始就修改以下四项USER_AGENT Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ROBOTSTXT_OBEY True DOWNLOAD_DELAY 1.5 CONCURRENT_REQUESTS 8USER_AGENT伪装成常规浏览器是绝大多数站点最基本的要求ROBOTSTXT_OBEY打开后Scrapy会先检查目标站的robots.txt是否允许抓取指定路径这是合规的第一道门槛DOWNLOAD_DELAY是请求间隔越大越安全CONCURRENT_REQUESTS是并发数。这四个参数是“安全起步”的基本配置。4. 数据落地与去重机制Pipeline和过滤器实战解析4.1 Item Pipeline的典型应用Pipeline能做的事情远比“存数据库”丰富得多。我把日常开发中最常用的几种场景列出来供你对照自己的需求场景Pipeline动作示例实现思路字段清洗去除空格、替换非法字符process_item里做strip操作数据校验必填字段缺失则丢弃检查Item中字段为None则raise DropItem去重相同数据不重复入库用集合记录已见过的唯一键多端存储同时写CSV和数据库配置两条Pipeline按顺序执行数据转换字符串数字转float在Pipeline里统一处理分发通知异常数据推送告警捕获异常后打日志发消息拿数据校验举例一个典型的“丢弃脏数据”Pipeline长这样from scrapy.exceptions import DropItem class RequiredFieldsPipeline: def process_item(self, item, spider): if not item.get(title): raise DropItem(fMissing title in {item}) return item被raise DropItem的Item不会进入后续Pipeline这个机制配合日志可以非常方便地统计抓取质量。4.2 URL去重与重复数据问题Scrapy默认自带一个去重机制基于Request的指纹指纹由请求方法与URL等参数计算。同一个URL只会被下载一次。但实际项目中还有两类常见的重复问题内容重复但URL不同比如带各种追踪参数的URL、同一商品的不同入口链接翻页循环比如下一页链接把自己拼到无限长。针对内容重复我会在Pipeline里用“唯一键集合”再做一道去重。更稳妥的做法是引入布隆过滤器在请求层面就把相似参数归一化。针对翻页循环需要你在Spider里仔细控制终止条件不要只依赖“next_page为空就停”某些站点会把当前页URL伪装成下一页导致死循环。4.3 一个图书网站抓取的完整Pipeline配置我以前写过一个抓图书数据的爬虫Pipeline的配置顺序是这样的先字段清洗再必填校验最后写MongoDB。清洗的逻辑简单但很实用——把价格从“£51.77”这种文本转成51.77这个浮点数把评分从“Three”转成3。class CleanPipeline: def process_item(self, item, spider): price item.get(price, 0) item[price] float(price.replace(£, ).strip()) if item.get(rating): rating_map {One: 1, Two: 2, Three: 3, Four: 4, Five: 5} item[rating] rating_map.get(item[rating], 0) return item在配置顺序上清洗Pipeline的数值要比存储Pipeline小这样才能保证入库前数据已经是干净状态。数值间隔我习惯留100方便以后在中间插入新的Pipeline。这里有个值得一提的细节Scrapy的Pipeline机制默认是“链式传递”。每个Pipeline的process_item方法拿到上一步返回的item处理完再传给下一步。如果你在流程中间return了None这条数据就断在这儿了。所有离开爬虫的数据都必须以Item或字典的形式走完整条链路。5. 反爬应对策略与合规操作边界5.1 常见反爬机制和针对性处理思路爬虫写得好不好一半体现在应对反爬的能力上。常见机制和常规处理思路大致如下反爬手段表现方式常规应对策略User-Agent检查拒绝非浏览器请求随机切换UA池请求频率限制出现验证码或封IP调大DOWNLOAD_DELAYCookie校验未登录态直接跳转登录后保持Cookie页面动态渲染数据由JS加载换用渲染工具配合WebDriver检测检测自动化浏览特征修改指纹参数关于随机UA可以自己维护一个列表在Downloader Middleware里随机选择。复杂一点可以用现成的第三方UA库但核心逻辑都一样。某个站点如果对访问频率极其敏感设置UA的作用就有限了真正起作用的往往是请求间隔和代理池。5.2 请求头、Cookie与代理的配置请求头里面除了User-Agent还有Referer、Accept-Language等。很多站点的后端会校验Referer是否来自自己的页面这种情况我会在爬虫里动态补上模拟真实的浏览路径。Cookie方面最简单的方案是打开浏览器里的开发者工具复制当前的Cookie头放到Request里直接带上。但Cookie会过期长期运行需要换成登录接口动态获取。我常用的做法是把登录和爬取分开先用Requests完成登录拿到Cookie再通过Middleware注入到每个请求里。5.3 合规边界别踩线这一段我想多说几句。爬虫虽然技术上有很强的“对抗性”但使用边界必须清晰。我给自己的项目定了几条硬规矩遵守robots.txt的声明不爬明确禁止的路径请求频率保持在人类浏览水平不加压公开数据用于学习研究不涉及隐私与版权内容不对站点造成可用性损害这三条原则不一定能帮你“抓到更多数据”但能保证你的项目在灰色地带里站得住脚。技术能力再强也别把爬虫做成对目标站点的攻击性工具。个人学习抓一点公开数据没问题但大规模采集生产数据前先想清楚用途是否合法合规。6. 性能调优与生产环境部署要点6.1 并发量与请求延迟的动态平衡Scrapy性能调优的核心就一句话在目标站点能承受的前提下最大化吞吐量。实践中需要根据目标站点的反应动态调整两个参数CONCURRENT_REQUESTS和DOWNLOAD_DELAY。我曾经抓过某小型BBS用Settings.py里默认的并发就触发了封禁策略降到每秒一个请求才恢复正常。后来总结的经验是遇到封禁不要急着加代理先看自己的请求频率是否人道。毕竟国内很多站点防护规则很简单——单IP频率超过阈值直接拉黑。如果目标站点响应速度很稳定还可以把DOWNLOAD_DELAY设为0只保留一小段随机延迟配合较大的CONCURRENT_REQUESTS通常能获得不错的吞吐量。比较稳妥的起步参数区间是延迟1到2秒并发8到16。在此基础上逐步下调延迟直到出现异常再回退一档。6.2 常见坑与排查思路下面这些坑我几乎在带新人时都会再踩一遍先列出来帮大家避雷DEBUG日志里能看到Response但parse不执行——多半是回调函数写错名字或请求被回调函数返回的Item打断。抓下来的数据全部重复而且越抓越多——去重键没设计好可能是URL带了变化的时间戳参数。Pipeline一个都没执行——检查settings.py里ITEM_PIPELINES的配置是否生效有没有拼错类路径。日志提示“Filtered offsite”——Scrapy默认的安全机制防止拿A站点的链接去B站点下载检查Spider的allowed_domains。scrapy crawl后一个请求都不发——先看robots.txt是否设为False再看start_urls是否拼错。排查的顺序我建议遵循先看日志级别Scrapy的INFO和DEBUG日志信息量很大再看目标站点是否有响应异常最后才查代码逻辑。很多时候是配置问题而非代码问题。6.3 从单机到分布式扩展思路单机Scrapy跑批量数据通常够用。但如果数据量极大就需要扩展。极简方案是借助第三方调度器把Scheduler替换成基于Redis的共享队列让多台机器共用同一个待抓取集合。Spider代码改动很小主要在settings.py里换掉调度器配置。另一种轻量做法是把Requests直接写成独立任务用消息队列分发给多台机器每台机器跑一个独立的Scrapy爬虫。但这样去重会分散需要额外统一管理抓取指纹。我个人的建议是先确认单机瓶颈在哪再做分布式。如果瓶颈在网络延迟与目标站点限制分布式收效甚微如果瓶颈在解析密集型任务与本地存储分布式才有意义。分布式带来的管理复杂度提升不是一星半点为一个千级页面项目上分布式纯属给自己找麻烦。写在最后的一些经验搜了一圈资料写这篇文章顺手把这几年的笔记也翻了翻。有些经验我觉得值得单独拿出来说Scrapy的易用性有一个“迷惑期”——你得写出第一个能稳定跑完的爬虫才真正入门。别再纠结框架本身遇到问题先直接看Stack Overflow再不行就查文档文档里的示例质量很高。最有效的学习路径是拿一个真实站点从头到尾写一个完整的爬虫过程中把Pipeline、Middleware、Shell调试都过一遍比刷什么教程都管用。还有一点补充给正在做采集项目的读者数据落库之前一定要留一份原始响应。我习惯在Pipeline里把每个页面的原始HTML存一份方便后续字段遗漏时重新解析省得重新爬一遍。这个小习惯在长期项目里救过我很多次。最后再分享一个小技巧在settings.py里加一个自定义的LOG_LEVEL配置主流程用INFO业务代码里用DEBUG记录关键数据流向比如“正在处理第N个详情页”。跑批任务的时候把日志保存到文件出错后不用重新调试直接对着日志定位现场。Scrapy的日志系统扩展性很强值得花时间建立自己的日志习惯。抓取这件事技术本身不复杂做精的功夫都在细节里。希望这篇文章对你有所帮助。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
