简介这是一套面向Python初学者与爬虫实践者的校园集市数据采集项目源码基于Scrapy框架构建适用于高校信息分析、二手交易数据研究及Web数据工程入门学习。资源共48个文件包含24个Python源文件涵盖spiders、pipelines、utils等核心模块、11个文本类文件含readme、说明文档及环境依赖配置、2个SQL脚本用于MySQL建表与初始化、1个cfg配置文件及许可证等辅助文件整体压缩包仅1.33MB轻量易部署。已有77人下载学习适合快速掌握Scrapy项目结构、中间件配置、数据清洗管道与数据库持久化全流程。项目目录层次清晰含热榜算法Heat_Algorithm、情感评分sentiment_Rating、词向量相关性计算correlation_cal_w2c/bert等扩展模块附赠内容还包含OCR识别与停用词处理工具为后续数据分析提供完整支撑。 校园集市这类数据蹲过学校论坛或者二手群的人都懂信息零零散散刷起来费劲想搜个“自行车”得翻几十页帖子。我做的这个项目就是用Python的Scrapy框架把某类校园集市站点上的商品信息抓下来清洗好落进数据库做增量更新和二次检索。对正在学爬虫、或者拿它当毕业设计题目的同学来说这篇记录可以当成一份完整的设计说明书来看整个项目的拆解思路、源码结构、踩坑过程都在里面。1. 项目整体设计与技术选型思路1.1 校园集市的数据场景到底长什么样校园集市和大众电商平台最大的区别在于数据量不大但信息密度高、更新极快。一个学校一天的二手发帖量可能只有几十到几百条但每条都包含价格、成色描述、联系方式、交易方式这些关键信息。而且这类站点形态很杂常见的有三种论坛插件版块Discuz、phpBB之类、学校自建的H5商城、还有微信小程序的前端页面。不管哪种形态背后基本都是服务端渲染的HTML页面或者是Ajax接口返回的JSON只要找到数据来源抓取本身并不复杂。我当时做这个项目核心需求是三点第一把散落在不同板块的商品信息聚合到一个地方方便按关键词搜索第二对新增商品做订阅提醒比如有人挂了“显示器”就通知我第三积累一段时间的数据看看校园二手交易的行情波动。第三点是后来加的需求也正因为有这个目标我在字段设计上从一开始就预留了时间和价格两个关键维度方便后续做分析。这个数据场景其实非常适合用Scrapy来做原因也很直接目标站点结构清晰、层级不深列表页到详情页最多两层、数据字段统一。相比之下如果去爬电商大平台光是应对反爬和复杂页面就要消耗大量精力而校园集市普遍反爬力度低更适合把一个完整的数据爬取流程跑通。1.2 为什么选Scrapy而不是requests加BeautifulSoup很多初学者第一次写爬虫都会从requests加BeautifulSoup或者Selenium开始。这没有问题我初期拿来做快速原型也挺顺手。但一旦你的需求变成“长期、定时、增量地爬取一个站点的结构化数据”requests脚本的几个痛点就会暴露出来。最明显的是并发和异常处理。requests脚本想要并发抓取需要自己用ThreadPoolExecutor或者asyncio去管理线程池还要自己写失败重试、超时控制、请求头轮换。Scrapy把这些都内置了异步并发框架、下载中间件、重试中间件开箱即用你只需要关心“怎么解析”和“怎么存”不用重复造轮子。第二个痛点是去重和任务调度。Scrapy自带的调度器天然支持去重对同一个URL默认只抓一次这对爬虫来说是刚需。脚本方案里你要自己去维护一个set或者数据库表来判断哪些URL已经爬过了写多了容易出bug。第三个痛点是扩展性。我的项目后来加了Scrapy-Redis做分布式加了Playwright处理动态页面这些都是Scrapy生态里的成熟组件。如果当初用requests脚本这些扩展都要从零开始写。1.3 源码模块怎么分层一个清晰的Scrapy工程长什么样Scrapy框架本身给了明确的模块划分但很多初学者用着用着就乱了所有逻辑都塞spider文件里Pipeline里写一堆判断settings随意调。我这个项目一开始就定了每个文件只干一件事的原则。spiders/只负责请求和解析拿到Item就交给Pipeline。items.py定义数据模型相当于数据库表结构的前置映射。pipelines.py数据清洗、去重、入库所有脏活都放这里。middlewares.py请求头轮换、代理切换、异常捕获。settings.py只放配置不写业务逻辑。utils/时间解析、价格清洗、通用函数。这样一个分层的好处你改任何一个环节都不影响其他部分。比如后来站点改版商品详情从静态HTML变成了Ajax接口我只需要改spider里的解析逻辑Pipeline和Middleware完全不用动。如果你拿这个项目当毕业设计这种清晰的分层在答辩的时候也特别好讲每一层都能对应到框架的一个设计理念。2. 核心细节解析与实操要点2.1 商品Item字段设计不是随便写几个字段就完事我见过很多爬虫项目的Item就写两三个字段然后所有信息都塞到description里。这样做当时省事后面做检索和统计的时候就想哭了。我的字段设计如下title商品标题用于搜索和列表展示。price商品价格用Decimal类型存储不用字符串。raw_price原始价格字符串保留现场方便排查解析问题。description商品详细描述。image_urls商品图片链接列表。seller_name发布者昵称。publish_time发布时间统一转成datetime类型。source_url来源页面URL。url_hashsource_url的MD5值作为去重唯一键。crawl_time抓取时间用于增量更新和数据分析。价格为什么不用字符串因为后续要算均价、做价格区间分析字符串没法直接聚合。Decimal则是为了避免浮点精度问题0.1加0.2这种事情在二进制浮点里会出幺蛾子数据库里对应decimal类型两边严丝合缝。raw_price字段很多人觉得冗余其实非常有用解析逻辑出问题的时候拿raw_price一对比就能看出清洗环节哪里写错了。url_hash唯一键是整个去重机制的基础入库时用INSERT IGNORE或者ON DUPLICATE KEY UPDATE数据库层面就挡住了重复数据。这个字段看起来不起眼但在增量爬取场景下就是定海神针。2.2 列表页抓索引、详情页补全信息的双阶段策略校园集市这类站点有两种典型的信息分布方式一种是列表页直接展示全部商品字段另一种是列表页只给标题和价格描述和图片得进详情页才看得到。我自己的项目里碰到了混合情况所以采用了双阶段策略。第一个阶段spider先从列表页提取每一件商品的基本信息和详情页URL组装成一个轻量Item直接进Pipeline。第二阶段对每个详情页URL发起请求解析出完整描述和图片再更新到数据库里。这么设计的原因很现实如果详情页反爬严格或者加载缓慢至少列表页的标题、价格已经拿到了不会颗粒无收。而且详情页请求天然比列表页慢双阶段可以让我控制详情页的并发和延时不至于打爆目标站点。实现上只需要在parse方法里把列表页和详情页分成两个回调函数列表页yield Request交给parse_detail同时yield Item把基础信息交给Pipeline。2.3 翻页机制与防重复的设计细节翻页是爬虫入门必踩的坑之一。我见过最典型的错误是直接把第1页到第999页全部塞进start_urls不管站点实际有没有那么多页面。正确做法是在解析当前页时提取“下一页”链接交给Scrapy的调度器去处理这样天然不会多爬不存在的页面。但这里有个细节有些站点的“下一页”链接是动态生成的比如下一页的页码藏在JavaScript变量里或者使用了无限滚动加载。对于前者可以用XPath匹配页码变量然后拼接URL对于后者往往意味着数据来自Ajax接口需要找到接口地址直接请求这就是我后面接Playwright或者直接对接接口的原因。防重复方面我的原则是两层都做Scrapy调度器自带URL去重解决同一个URL不重复请求的问题数据库的url_hash唯一索引解决同一商品被不同入口重复收录的问题。这两层配合起来增量爬取时才不会数据翻倍。2.4 数据清洗Pipeline坑最多的地方数据清洗是爬虫项目里最容易被低估的部分。校园集市的数据特点是“高度非标准化”一个价格字段可能写成“80元”、“¥80”、“80包邮”、“可小刀”你要全部归一化成80这个数字。我写了一个专门的清洗函数来处理这个问题先去掉所有非数字字符再判断是否包含“包邮”“小刀”这类描述词进行加权判断。更麻烦的是发布时间校园集市特别喜欢用“刚刚”、“5分钟前”、“昨天 14:32”这种相对时间必须自己写解析逻辑把相对时间转成绝对时间。我的做法是用正则匹配时间关键词然后以当前时间为基准做减法再转成数据库里的datetime格式。时间解析有一个坑必须提醒你不要把服务器当前时间直接当成发布时间。爬虫运行时间和你看到页面的时间是有延迟的如果站点返回的是绝对时间还好如果是相对时间必须把“爬虫发起请求的时间”作为基准而不是“程序跑到这里的时间”。我一开始没注意这个问题导致发布时间的统计结果跟实际情况偏差很大后来在请求返回时就把时间戳记录到meta里才彻底解决。3. 实操过程与核心环节实现3.1 环境准备与项目初始化这一步比较基础但如果你是在Windows上做有几个小问题容易绊倒人。首先是Python版本我推荐3.9或3.10太新的版本某些Scrapy扩展可能还没有编译好的wheel包。建议用虚拟环境安装避免全局环境被搞乱python -m venv venv source venv/bin/activate # Windows上是 venv\Scripts\activate pip install scrapy pip install scrapy-redis # 后续扩展用 pip install playwright # 处理动态页面用然后创建项目骨架scrapy startproject campus_market cd campus_market scrapy genspider market_spider your-campus-market-domain.com生成的目录结构是Scrapy的标准模板你会在里面看到items.py、middlewares.py、pipelines.py、settings.py这些文件。第一次跑的时候先用scrapy shell命令去目标站点手动测试一下选择器确认字段能正确提取再写正式逻辑这个习惯能省下一堆调试时间。3.2 核心Spider源码附逐段注释Spider是整个项目的主引擎我简化出来一个版本方便说明。目标站点的列表页结构假设是这样的每个商品在一个div.market-item里标题在.hd a里面价格在.price里面详情链接在标题a的href属性里。import hashlib import scrapy from scrapy.http import Request from campus_market.items import CampusMarketItem class MarketSpider(scrapy.Spider): name market_spider allowed_domains [your-campus-market-domain.com] start_urls [https://your-campus-market-domain.com/list/1] def parse(self, response): # 第一步解析列表页提取商品基础信息 item_nodes response.css(div.market-item) for node in item_nodes: title node.css(.hd a::text).get() price_text node.css(.price::text).get() detail_url node.css(.hd a::attr(href)).get() if not detail_url: continue detail_url response.urljoin(detail_url) item CampusMarketItem( titletitle.strip() if title else , raw_priceprice_text.strip() if price_text else , source_urldetail_url, url_hashhashlib.md5(detail_url.encode()).hexdigest(), ) # 先上交基础信息再去请求详情页 yield item yield Request(urldetail_url, callbackself.parse_detail, meta{url_hash: item[url_hash]}) # 第二步跟进下一页 next_page response.css(a.next::attr(href)).get() if next_page: yield Request(urlresponse.urljoin(next_page), callbackself.parse) def parse_detail(self, response): url_hash response.meta[url_hash] description response.css(.detail-content::text).get() images response.css(.detail-content img::attr(src)).getall() publish_time_text response.css(.publish-time::text).get() seller_name response.css(.seller-name::text).get() # 把详情页补全的信息以更新包的形式继续交给 Pipeline yield CampusMarketItem( url_hashurl_hash, descriptiondescription.strip() if description else , image_urls[response.urljoin(img) for img in images], seller_nameseller_name.strip() if seller_name else , publish_timeresponse.meta.get(publish_time), )这段代码有几点值得展开说。第一列表页先yield一个不完整的Item再yield详情页请求这不是乱序而是Pipeline里去重逻辑要保证同一url_hash先插入基础信息后面再更新完整信息。第二使用urljoin处理相对路径避免图片和详情链接因为路径问题变成废数据。第三meta传参把列表页已算好的url_hash带给详情页这样详情页更新的时候不需要重新计算哈希。3.3 中间件与反爬细节配置校园集市虽然反爬力度低但服务器安全软件还是有的UA一不对劲就403。我在middlewares.py里做了三件事User-Agent轮换、代理开关、异常状态码日志。import random from scrapy.downloadermiddlewares.retry import RetryMiddleware class RandomUserAgentMiddleware: 随机UA模拟不同浏览器访问 user_agents [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15, Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15, ] def process_request(self, request, spider): request.headers[User-Agent] random.choice(self.user_agents) return None class CustomRetryMiddleware(RetryMiddleware): 扩展重试逻辑把403也加入重试范围但降低重试次数 EXCEPTIONS_TO_RETRY (403, 429, 500, 502, 503, 504) def process_response(self, request, response, spider): if response.status in self.EXCEPTIONS_TO_RETRY: reason fstatus_code: {response.status} return self._retry(request, reason, spider) or response return response这些中间件要记得在settings.py里启用并且注意顺序。CustomRetryMiddleware放在RetryMiddleware的后面才能覆盖默认的重试逻辑否则框架的默认中间件会先处理response403直接就被丢弃了。3.4 数据落库MySQL表结构、Pipeline与去重插入数据库我用的是MySQL表结构设计得很精简所有字段都有明确用途CREATE TABLE market_item ( id INT AUTO_INCREMENT PRIMARY KEY, url_hash CHAR(32) NOT NULL UNIQUE, title VARCHAR(255) NOT NULL DEFAULT , price DECIMAL(10, 2) DEFAULT NULL, raw_price VARCHAR(100) DEFAULT NULL, description TEXT, image_urls TEXT, seller_name VARCHAR(100) DEFAULT , publish_time DATETIME DEFAULT NULL, crawl_time DATETIME NOT NULL, KEY idx_publish_time (publish_time), KEY idx_price (price) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;url_hash上加了唯一索引这就是我之前说的数据库层去重。Pipeline里的插入逻辑用ON DUPLICATE KEY UPDATE实现“存在就更新不存在就插入”class MySQLPipeline: def process_item(self, item, spider): # item里有的字段才更新没有的字段不动 update_fields [] values [] for field in item.fields: if field in item and item.get(field) is not None: update_fields.append(f{field} %s) values.append(item.get(field)) sql ( INSERT INTO market_item (url_hash, title, price, raw_price, description, image_urls, seller_name, publish_time, crawl_time) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE , .join(update_fields) ) values self._format_values(item, values) self.cursor.execute(sql, values) self.conn.commit() return item这里有个细节price字段在进入SQL之前要转成Decimalpublish_time要转成datetimecrawl_time直接用datetime.now()。这些转换逻辑我放在Pipeline入口处单独写了一个_format_values方法避免在spider里塞太多业务。批量写入方面如果数据量到了每天几千条逐条commit其实性能也能接受毕竟校园集市不是电商平台。但如果真的想优化可以攒一批再commitScrapy的pipeline本身是串行调用process_item的要批量写入需要自己维护一个缓冲列表到一定大小再flush。这个我放在扩展章节里讲。3.5 Settings调参我实测的一组稳定配置Settings是Scrapy项目的控制台参数非常多但真正影响校园集市项目稳定性的就那么几个。下面这组是我在项目里实测跑了两周没出问题的配置BOT_NAME campus_market ROBOTSTXT_OBEY False # 目标站点没有robots限制且有合理抓取需求 DOWNLOAD_DELAY 1.5 CONCURRENT_REQUESTS 8 CONCURRENT_REQUESTS_PER_DOMAIN 4 AUTOTHROTTLE_ENABLED True AUTOTHROTTLE_START_DELAY 1.0 AUTOTHROTTLE_MAX_DELAY 10.0 COOKIES_ENABLED True RETRY_ENABLED True RETRY_TIMES 2 RETRY_HTTP_CODES [403, 429, 500, 502, 503, 504, 522] DEFAULT_REQUEST_HEADERS { Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, }DOWNLOAD_DELAY设成1.5秒CONCURRENT_REQUESTS设成8意味着每个请求之间至少间隔1.5秒8个并发叠加起来对目标站点很克制但又不会慢到无法接受。AUTOTHROTTLE是Scrapy的自动限速它会根据服务器的响应时间动态调整延迟比手动设置更智能。校园集市这类站点服务器处理速度本身不慢AUTOTHROTTLE会自动找到一个安全的抓取节奏。很多人习惯把DOWNLOAD_DELAY设成0.1甚至不设结果就是刚跑几十个请求就被封了IP或者触发验证码。爬虫不是抢火车票数据质量比速度重要得多尤其是做长期增量采集稳定才能持久。4. 常见问题与排查技巧实录4.1 403频繁出现怎么排查403是爬虫最常遇到的状态码我排查的顺序固定是先看User-Agent再看Referer再看Cookie最后才是IP封禁。原因很简单前三个都是你自己能控制的IP封禁则要上代理池成本最高。用scrapy shell手动请求一下带上浏览器的完整请求头如果返回正常那问题就在请求头配置上。如果带上完整请求头还是403那才考虑是IP维度的封禁需要降低并发、拉大延时或者用代理池。我之前遇到一个特例校园集市某个页面对Cookie做校验必须先从首页拿到会话Cookie再带着这个Cookie去请求列表页。解决方式是在start_requests里先请求一下首页把Cookie放到meta里传给后续请求或者用Scrapy的CookiesMiddleware自动维护会话。4.2 动态渲染的列表页抓不到数据怎么办如果你的目标站点是纯JavaScript渲染或者用了iframe嵌入商品列表Scrapy默认的HTML解析是拿不到数据的因为请求返回的HTML里根本没有商品节点。我有两个处理思路。第一个思路是找接口。浏览器开发者工具里切到Network面板刷新页面看哪些XHR请求返回了商品JSON数据。直接请求这个接口解析JSON比任何渲染方案都快都稳。这个方法能解决80%的“动态页面”问题。第二个思路才是用Playwright因为我项目里确实遇到一个iframe嵌套的场景商品列表在一个二级iframe里而且iframe的URL是动态生成的。Playwright能驱动真实浏览器把渲染完成后的HTML抓回来再喂给Scrapy解析。用的时候注意控制并发浏览器实例很吃资源。参考做法是写一个下载中间件当Spider发出的请求标记为需要用浏览器渲染时就调用Playwright去打开页面、等待加载完成返回渲染后的response。热词里提到的scrapyplaywright就是这个路线完整解决方案还需要考虑Playwright启动的异步事件循环和Scrapy的兼容但作为过渡方案已经够用。4.3 重复数据多、断点续爬怎么做重复数据的来源通常是两个一个是同一个商品被多个入口收录比如搜索页和列表页都包含了它另一个是重跑爬虫时没有清空上次的去重队列。Scrapy默认的去重是针对同一个Spider运行过程的每次运行结束队列就清了增量爬取时旧数据会重新进入。我的解决方案分两半。数据库层面的url_hash唯一索引是第一道防线这保证了物理上不可能有重复行。第二道防线是Scrapy的请求去重如果你要跨运行保持去重状态可以用scrapy-redis的RFPDupeFilter把请求指纹存在Redis里重跑时自动跳过已经抓过的URL。如果你不想引入Redis另一个简单做法是在Spider的start_requests里先查数据库已有的url_hash集合然后过滤掉这些URL。断点续爬是一个被低估的需求Scrapy自带的JOBDIR参数可以做到scrapy crawl market_spider -s JOBDIRcrawls/market_spider设置这个参数后Scrapy会保存运行状态下次启动时可以接着上次的进度继续爬。对校园集市这种日常几十页的站点这个功能用不用其实无所谓但如果哪次你跑了上万条数据然后中断了就明白这个参数有多救命了。4.4 入库乱码与字段截断问题MySQL入库乱码十有八九是字符集没配对。建表的时候用了utf8mb4但连接字符串里还带着旧的charsetutf8或者数据库连接池配置里没指定字符集结果中文全部变成问号。我在settings.py里配置数据库连接时会明确加上charsetutf8mb4并在MySQL的connection里设置init_commandMYSQL_CONFIG { host: 127.0.0.1, port: 3306, user: root, password: your_password, database: campus_market, charset: utf8mb4, }字段截断问题则是另一类VARCHAR长度不够比如某条商品标题特别长超过255字符插入时就被数据库截断或者直接报错。我在Pipeline里会提前判断长度超标的字段做截断处理避免入库时才发现。另外description字段用TEXT但TEXT最大只能存65535字节足够用了如果遇到超长描述做摘要存储即可。4.5 收录数据量远少于预期问题可能出在哪爬虫跑完一看网站上有500条数据我库里只有200条这种问题我遇到过好几次。老手排查的顺序是先看日志里有没有异常状态码再看选择器返回的列表长度再看是不是页面结构有分页之外的加载逻辑。最常见的原因有三个。第一选择器写错这个用scrapy shell测试就能验证。第二页面其实存在“按板块分类”的逻辑你只爬了默认板块。第三商品列表不是一次性加载完的可能滚动到底部才触发加载更多这时候要么找接口要么用Playwright模拟滚动。我建议从一开始就在Spider里加一个简单统计每页解析到的条目数、成功入库数、失败数打印到日志里。数据量大不大一跑就知道哪个环节丢了。4.6 常见问题速查表症状排查方向通常解法所有请求返回403UA/Referer/Cookie再到IP轮换UA、补请求头、降并发列表页能打开但解析不到数据JS渲染或iframeF12找接口或用Playwright重复数据多URL去重失效/数据库无唯一键加url_hash唯一索引用Redis去重中文乱码字符集不匹配建表和连接都换utf8mb4入库字段截断VARCHAR长度不足提前截断或换TEXT收录数量少分页/板块/懒加载看日志统计找遗漏入口运行中途崩了目标站反爬/自身异常加JOBDIR断点续爬5. 可复用的扩展路线与我的实操心得5.1 单机爬虫升级Scrapy-Redis的时机热词里提到了scrapy-redis这是一个非常经典的扩展核心价值是把爬虫的调度器和去重队列从单机内存搬到Redis里让多台机器可以共同消费同一个URL队列。但我想说校园集市这个体量绝大多数情况下用不上分布式。我自己测试过单机跑校园集市一天抓一万条数据轻轻松松而校园集市全站可能也就几千条商品。什么时候才需要Scrapy-Redis当你的爬虫数量上来了比如同时爬10个学校、每个站点每天几万条更新单机调度器和去重队列会成为瓶颈而且一台机器挂了整个任务就断了。这时候用Scrapy-Redis多台服务器分担压力队列在Redis里不会丢。另外如果你需要多个Spider共享去重状态比如A爬虫和B爬虫爬的是同一个站点的不同板块不希望重复抓同一个商品Redis去重也比分库分表简单。落地时改动不大settings里加几行配置把scheduler换成RedisSchedulerdupefilter换成RFPDupeFilter再指定Redis连接地址就行。唯一要注意的是Redis里存的请求指纹会越来越多需要定期清理或者设置过期策略。5.2 爬虫数据要变成可用服务还差哪几步爬虫只是数据链路的前半段数据到库里了得让用户能用起来才算完成。我的项目后期加了一个简单的搜索接口用Flask起了一个HTTP服务查询逻辑很简单商品标题做模糊匹配发布时间倒序排列。后面又给接口加了分页和价格区间筛选前端是一个极简的HTML页面输入关键词就能列出最新的二手信息。再往后我还做了一件比较有意思的事把每天新增的商品抓完后自动生成一份“今日校园二手行情摘要”统计当天发布的商品数、热门类目、价格分布推送到我的个人邮箱。这个功能实现起来不复杂就是定时任务调爬虫抓完跑一段SQL做统计然后用smtplib发邮件。但就是这个看起来不起眼的扩展让爬虫从“一次性采集工具”变成了“持续运行的小服务”也把整个项目的价值感提升了一个档次。5.3 我踩过的坑和现在的做法最后分享几个我现在固定在用的习惯。第一所有字段解析都写容错get不到就赋空值绝不让一个字段解析异常导致整条Item丢失。第二每次爬完跑一遍对账SQL比如SELECT COUNT(*)对比来源站点商品数和数据库数发现差太多立刻查日志。第三爬虫代码写完之后先用scrapy parse命令挂在目标URL上跑通了解析逻辑再正式启动全量爬取这个习惯帮我避掉了至少一半的返工。另外一个很重要的观念爬虫项目运行时间越长越要重视运行状态的监控。我现在会在Pipeline里埋一个进度计数器每处理100条Item打印一次统计配合LOG_LEVEL设置为INFO实时观察爬虫运行状态。遇到站点改版导致解析失效时一天之内就能发现问题而不是等用户反馈了才知道。这个项目从最初的一个简单爬虫脚本到后来能稳定增量更新、有搜索接口、有行情摘要的小系统前前后后跑了快两个月。最深的体会是爬虫项目的难点从来不在于把网页数据抓下来而在于数据抓下来之后怎么清洗得干净、怎么存得合理、怎么不重不漏、怎么持续稳定运行。如果你也是拿这个题目练手建议先把Item设计和Pipeline这块做扎实数据结构设计对了后面的扩展才不至于推倒重来。一个小技巧每次爬完花两分钟用SQL做一次数据量对账看起来简单但真的能帮你省下大量排查问题的时间。本文还有配套的精品资源点击获取 校园集市数据爬取：Scrapy框架实战与增量更新方案
简介这是一套面向Python初学者与爬虫实践者的校园集市数据采集项目源码基于Scrapy框架构建适用于高校信息分析、二手交易数据研究及Web数据工程入门学习。资源共48个文件包含24个Python源文件涵盖spiders、pipelines、utils等核心模块、11个文本类文件含readme、说明文档及环境依赖配置、2个SQL脚本用于MySQL建表与初始化、1个cfg配置文件及许可证等辅助文件整体压缩包仅1.33MB轻量易部署。已有77人下载学习适合快速掌握Scrapy项目结构、中间件配置、数据清洗管道与数据库持久化全流程。项目目录层次清晰含热榜算法Heat_Algorithm、情感评分sentiment_Rating、词向量相关性计算correlation_cal_w2c/bert等扩展模块附赠内容还包含OCR识别与停用词处理工具为后续数据分析提供完整支撑。 校园集市这类数据蹲过学校论坛或者二手群的人都懂信息零零散散刷起来费劲想搜个“自行车”得翻几十页帖子。我做的这个项目就是用Python的Scrapy框架把某类校园集市站点上的商品信息抓下来清洗好落进数据库做增量更新和二次检索。对正在学爬虫、或者拿它当毕业设计题目的同学来说这篇记录可以当成一份完整的设计说明书来看整个项目的拆解思路、源码结构、踩坑过程都在里面。1. 项目整体设计与技术选型思路1.1 校园集市的数据场景到底长什么样校园集市和大众电商平台最大的区别在于数据量不大但信息密度高、更新极快。一个学校一天的二手发帖量可能只有几十到几百条但每条都包含价格、成色描述、联系方式、交易方式这些关键信息。而且这类站点形态很杂常见的有三种论坛插件版块Discuz、phpBB之类、学校自建的H5商城、还有微信小程序的前端页面。不管哪种形态背后基本都是服务端渲染的HTML页面或者是Ajax接口返回的JSON只要找到数据来源抓取本身并不复杂。我当时做这个项目核心需求是三点第一把散落在不同板块的商品信息聚合到一个地方方便按关键词搜索第二对新增商品做订阅提醒比如有人挂了“显示器”就通知我第三积累一段时间的数据看看校园二手交易的行情波动。第三点是后来加的需求也正因为有这个目标我在字段设计上从一开始就预留了时间和价格两个关键维度方便后续做分析。这个数据场景其实非常适合用Scrapy来做原因也很直接目标站点结构清晰、层级不深列表页到详情页最多两层、数据字段统一。相比之下如果去爬电商大平台光是应对反爬和复杂页面就要消耗大量精力而校园集市普遍反爬力度低更适合把一个完整的数据爬取流程跑通。1.2 为什么选Scrapy而不是requests加BeautifulSoup很多初学者第一次写爬虫都会从requests加BeautifulSoup或者Selenium开始。这没有问题我初期拿来做快速原型也挺顺手。但一旦你的需求变成“长期、定时、增量地爬取一个站点的结构化数据”requests脚本的几个痛点就会暴露出来。最明显的是并发和异常处理。requests脚本想要并发抓取需要自己用ThreadPoolExecutor或者asyncio去管理线程池还要自己写失败重试、超时控制、请求头轮换。Scrapy把这些都内置了异步并发框架、下载中间件、重试中间件开箱即用你只需要关心“怎么解析”和“怎么存”不用重复造轮子。第二个痛点是去重和任务调度。Scrapy自带的调度器天然支持去重对同一个URL默认只抓一次这对爬虫来说是刚需。脚本方案里你要自己去维护一个set或者数据库表来判断哪些URL已经爬过了写多了容易出bug。第三个痛点是扩展性。我的项目后来加了Scrapy-Redis做分布式加了Playwright处理动态页面这些都是Scrapy生态里的成熟组件。如果当初用requests脚本这些扩展都要从零开始写。1.3 源码模块怎么分层一个清晰的Scrapy工程长什么样Scrapy框架本身给了明确的模块划分但很多初学者用着用着就乱了所有逻辑都塞spider文件里Pipeline里写一堆判断settings随意调。我这个项目一开始就定了每个文件只干一件事的原则。spiders/只负责请求和解析拿到Item就交给Pipeline。items.py定义数据模型相当于数据库表结构的前置映射。pipelines.py数据清洗、去重、入库所有脏活都放这里。middlewares.py请求头轮换、代理切换、异常捕获。settings.py只放配置不写业务逻辑。utils/时间解析、价格清洗、通用函数。这样一个分层的好处你改任何一个环节都不影响其他部分。比如后来站点改版商品详情从静态HTML变成了Ajax接口我只需要改spider里的解析逻辑Pipeline和Middleware完全不用动。如果你拿这个项目当毕业设计这种清晰的分层在答辩的时候也特别好讲每一层都能对应到框架的一个设计理念。2. 核心细节解析与实操要点2.1 商品Item字段设计不是随便写几个字段就完事我见过很多爬虫项目的Item就写两三个字段然后所有信息都塞到description里。这样做当时省事后面做检索和统计的时候就想哭了。我的字段设计如下title商品标题用于搜索和列表展示。price商品价格用Decimal类型存储不用字符串。raw_price原始价格字符串保留现场方便排查解析问题。description商品详细描述。image_urls商品图片链接列表。seller_name发布者昵称。publish_time发布时间统一转成datetime类型。source_url来源页面URL。url_hashsource_url的MD5值作为去重唯一键。crawl_time抓取时间用于增量更新和数据分析。价格为什么不用字符串因为后续要算均价、做价格区间分析字符串没法直接聚合。Decimal则是为了避免浮点精度问题0.1加0.2这种事情在二进制浮点里会出幺蛾子数据库里对应decimal类型两边严丝合缝。raw_price字段很多人觉得冗余其实非常有用解析逻辑出问题的时候拿raw_price一对比就能看出清洗环节哪里写错了。url_hash唯一键是整个去重机制的基础入库时用INSERT IGNORE或者ON DUPLICATE KEY UPDATE数据库层面就挡住了重复数据。这个字段看起来不起眼但在增量爬取场景下就是定海神针。2.2 列表页抓索引、详情页补全信息的双阶段策略校园集市这类站点有两种典型的信息分布方式一种是列表页直接展示全部商品字段另一种是列表页只给标题和价格描述和图片得进详情页才看得到。我自己的项目里碰到了混合情况所以采用了双阶段策略。第一个阶段spider先从列表页提取每一件商品的基本信息和详情页URL组装成一个轻量Item直接进Pipeline。第二阶段对每个详情页URL发起请求解析出完整描述和图片再更新到数据库里。这么设计的原因很现实如果详情页反爬严格或者加载缓慢至少列表页的标题、价格已经拿到了不会颗粒无收。而且详情页请求天然比列表页慢双阶段可以让我控制详情页的并发和延时不至于打爆目标站点。实现上只需要在parse方法里把列表页和详情页分成两个回调函数列表页yield Request交给parse_detail同时yield Item把基础信息交给Pipeline。2.3 翻页机制与防重复的设计细节翻页是爬虫入门必踩的坑之一。我见过最典型的错误是直接把第1页到第999页全部塞进start_urls不管站点实际有没有那么多页面。正确做法是在解析当前页时提取“下一页”链接交给Scrapy的调度器去处理这样天然不会多爬不存在的页面。但这里有个细节有些站点的“下一页”链接是动态生成的比如下一页的页码藏在JavaScript变量里或者使用了无限滚动加载。对于前者可以用XPath匹配页码变量然后拼接URL对于后者往往意味着数据来自Ajax接口需要找到接口地址直接请求这就是我后面接Playwright或者直接对接接口的原因。防重复方面我的原则是两层都做Scrapy调度器自带URL去重解决同一个URL不重复请求的问题数据库的url_hash唯一索引解决同一商品被不同入口重复收录的问题。这两层配合起来增量爬取时才不会数据翻倍。2.4 数据清洗Pipeline坑最多的地方数据清洗是爬虫项目里最容易被低估的部分。校园集市的数据特点是“高度非标准化”一个价格字段可能写成“80元”、“¥80”、“80包邮”、“可小刀”你要全部归一化成80这个数字。我写了一个专门的清洗函数来处理这个问题先去掉所有非数字字符再判断是否包含“包邮”“小刀”这类描述词进行加权判断。更麻烦的是发布时间校园集市特别喜欢用“刚刚”、“5分钟前”、“昨天 14:32”这种相对时间必须自己写解析逻辑把相对时间转成绝对时间。我的做法是用正则匹配时间关键词然后以当前时间为基准做减法再转成数据库里的datetime格式。时间解析有一个坑必须提醒你不要把服务器当前时间直接当成发布时间。爬虫运行时间和你看到页面的时间是有延迟的如果站点返回的是绝对时间还好如果是相对时间必须把“爬虫发起请求的时间”作为基准而不是“程序跑到这里的时间”。我一开始没注意这个问题导致发布时间的统计结果跟实际情况偏差很大后来在请求返回时就把时间戳记录到meta里才彻底解决。3. 实操过程与核心环节实现3.1 环境准备与项目初始化这一步比较基础但如果你是在Windows上做有几个小问题容易绊倒人。首先是Python版本我推荐3.9或3.10太新的版本某些Scrapy扩展可能还没有编译好的wheel包。建议用虚拟环境安装避免全局环境被搞乱python -m venv venv source venv/bin/activate # Windows上是 venv\Scripts\activate pip install scrapy pip install scrapy-redis # 后续扩展用 pip install playwright # 处理动态页面用然后创建项目骨架scrapy startproject campus_market cd campus_market scrapy genspider market_spider your-campus-market-domain.com生成的目录结构是Scrapy的标准模板你会在里面看到items.py、middlewares.py、pipelines.py、settings.py这些文件。第一次跑的时候先用scrapy shell命令去目标站点手动测试一下选择器确认字段能正确提取再写正式逻辑这个习惯能省下一堆调试时间。3.2 核心Spider源码附逐段注释Spider是整个项目的主引擎我简化出来一个版本方便说明。目标站点的列表页结构假设是这样的每个商品在一个div.market-item里标题在.hd a里面价格在.price里面详情链接在标题a的href属性里。import hashlib import scrapy from scrapy.http import Request from campus_market.items import CampusMarketItem class MarketSpider(scrapy.Spider): name market_spider allowed_domains [your-campus-market-domain.com] start_urls [https://your-campus-market-domain.com/list/1] def parse(self, response): # 第一步解析列表页提取商品基础信息 item_nodes response.css(div.market-item) for node in item_nodes: title node.css(.hd a::text).get() price_text node.css(.price::text).get() detail_url node.css(.hd a::attr(href)).get() if not detail_url: continue detail_url response.urljoin(detail_url) item CampusMarketItem( titletitle.strip() if title else , raw_priceprice_text.strip() if price_text else , source_urldetail_url, url_hashhashlib.md5(detail_url.encode()).hexdigest(), ) # 先上交基础信息再去请求详情页 yield item yield Request(urldetail_url, callbackself.parse_detail, meta{url_hash: item[url_hash]}) # 第二步跟进下一页 next_page response.css(a.next::attr(href)).get() if next_page: yield Request(urlresponse.urljoin(next_page), callbackself.parse) def parse_detail(self, response): url_hash response.meta[url_hash] description response.css(.detail-content::text).get() images response.css(.detail-content img::attr(src)).getall() publish_time_text response.css(.publish-time::text).get() seller_name response.css(.seller-name::text).get() # 把详情页补全的信息以更新包的形式继续交给 Pipeline yield CampusMarketItem( url_hashurl_hash, descriptiondescription.strip() if description else , image_urls[response.urljoin(img) for img in images], seller_nameseller_name.strip() if seller_name else , publish_timeresponse.meta.get(publish_time), )这段代码有几点值得展开说。第一列表页先yield一个不完整的Item再yield详情页请求这不是乱序而是Pipeline里去重逻辑要保证同一url_hash先插入基础信息后面再更新完整信息。第二使用urljoin处理相对路径避免图片和详情链接因为路径问题变成废数据。第三meta传参把列表页已算好的url_hash带给详情页这样详情页更新的时候不需要重新计算哈希。3.3 中间件与反爬细节配置校园集市虽然反爬力度低但服务器安全软件还是有的UA一不对劲就403。我在middlewares.py里做了三件事User-Agent轮换、代理开关、异常状态码日志。import random from scrapy.downloadermiddlewares.retry import RetryMiddleware class RandomUserAgentMiddleware: 随机UA模拟不同浏览器访问 user_agents [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15, Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15, ] def process_request(self, request, spider): request.headers[User-Agent] random.choice(self.user_agents) return None class CustomRetryMiddleware(RetryMiddleware): 扩展重试逻辑把403也加入重试范围但降低重试次数 EXCEPTIONS_TO_RETRY (403, 429, 500, 502, 503, 504) def process_response(self, request, response, spider): if response.status in self.EXCEPTIONS_TO_RETRY: reason fstatus_code: {response.status} return self._retry(request, reason, spider) or response return response这些中间件要记得在settings.py里启用并且注意顺序。CustomRetryMiddleware放在RetryMiddleware的后面才能覆盖默认的重试逻辑否则框架的默认中间件会先处理response403直接就被丢弃了。3.4 数据落库MySQL表结构、Pipeline与去重插入数据库我用的是MySQL表结构设计得很精简所有字段都有明确用途CREATE TABLE market_item ( id INT AUTO_INCREMENT PRIMARY KEY, url_hash CHAR(32) NOT NULL UNIQUE, title VARCHAR(255) NOT NULL DEFAULT , price DECIMAL(10, 2) DEFAULT NULL, raw_price VARCHAR(100) DEFAULT NULL, description TEXT, image_urls TEXT, seller_name VARCHAR(100) DEFAULT , publish_time DATETIME DEFAULT NULL, crawl_time DATETIME NOT NULL, KEY idx_publish_time (publish_time), KEY idx_price (price) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;url_hash上加了唯一索引这就是我之前说的数据库层去重。Pipeline里的插入逻辑用ON DUPLICATE KEY UPDATE实现“存在就更新不存在就插入”class MySQLPipeline: def process_item(self, item, spider): # item里有的字段才更新没有的字段不动 update_fields [] values [] for field in item.fields: if field in item and item.get(field) is not None: update_fields.append(f{field} %s) values.append(item.get(field)) sql ( INSERT INTO market_item (url_hash, title, price, raw_price, description, image_urls, seller_name, publish_time, crawl_time) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE , .join(update_fields) ) values self._format_values(item, values) self.cursor.execute(sql, values) self.conn.commit() return item这里有个细节price字段在进入SQL之前要转成Decimalpublish_time要转成datetimecrawl_time直接用datetime.now()。这些转换逻辑我放在Pipeline入口处单独写了一个_format_values方法避免在spider里塞太多业务。批量写入方面如果数据量到了每天几千条逐条commit其实性能也能接受毕竟校园集市不是电商平台。但如果真的想优化可以攒一批再commitScrapy的pipeline本身是串行调用process_item的要批量写入需要自己维护一个缓冲列表到一定大小再flush。这个我放在扩展章节里讲。3.5 Settings调参我实测的一组稳定配置Settings是Scrapy项目的控制台参数非常多但真正影响校园集市项目稳定性的就那么几个。下面这组是我在项目里实测跑了两周没出问题的配置BOT_NAME campus_market ROBOTSTXT_OBEY False # 目标站点没有robots限制且有合理抓取需求 DOWNLOAD_DELAY 1.5 CONCURRENT_REQUESTS 8 CONCURRENT_REQUESTS_PER_DOMAIN 4 AUTOTHROTTLE_ENABLED True AUTOTHROTTLE_START_DELAY 1.0 AUTOTHROTTLE_MAX_DELAY 10.0 COOKIES_ENABLED True RETRY_ENABLED True RETRY_TIMES 2 RETRY_HTTP_CODES [403, 429, 500, 502, 503, 504, 522] DEFAULT_REQUEST_HEADERS { Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, }DOWNLOAD_DELAY设成1.5秒CONCURRENT_REQUESTS设成8意味着每个请求之间至少间隔1.5秒8个并发叠加起来对目标站点很克制但又不会慢到无法接受。AUTOTHROTTLE是Scrapy的自动限速它会根据服务器的响应时间动态调整延迟比手动设置更智能。校园集市这类站点服务器处理速度本身不慢AUTOTHROTTLE会自动找到一个安全的抓取节奏。很多人习惯把DOWNLOAD_DELAY设成0.1甚至不设结果就是刚跑几十个请求就被封了IP或者触发验证码。爬虫不是抢火车票数据质量比速度重要得多尤其是做长期增量采集稳定才能持久。4. 常见问题与排查技巧实录4.1 403频繁出现怎么排查403是爬虫最常遇到的状态码我排查的顺序固定是先看User-Agent再看Referer再看Cookie最后才是IP封禁。原因很简单前三个都是你自己能控制的IP封禁则要上代理池成本最高。用scrapy shell手动请求一下带上浏览器的完整请求头如果返回正常那问题就在请求头配置上。如果带上完整请求头还是403那才考虑是IP维度的封禁需要降低并发、拉大延时或者用代理池。我之前遇到一个特例校园集市某个页面对Cookie做校验必须先从首页拿到会话Cookie再带着这个Cookie去请求列表页。解决方式是在start_requests里先请求一下首页把Cookie放到meta里传给后续请求或者用Scrapy的CookiesMiddleware自动维护会话。4.2 动态渲染的列表页抓不到数据怎么办如果你的目标站点是纯JavaScript渲染或者用了iframe嵌入商品列表Scrapy默认的HTML解析是拿不到数据的因为请求返回的HTML里根本没有商品节点。我有两个处理思路。第一个思路是找接口。浏览器开发者工具里切到Network面板刷新页面看哪些XHR请求返回了商品JSON数据。直接请求这个接口解析JSON比任何渲染方案都快都稳。这个方法能解决80%的“动态页面”问题。第二个思路才是用Playwright因为我项目里确实遇到一个iframe嵌套的场景商品列表在一个二级iframe里而且iframe的URL是动态生成的。Playwright能驱动真实浏览器把渲染完成后的HTML抓回来再喂给Scrapy解析。用的时候注意控制并发浏览器实例很吃资源。参考做法是写一个下载中间件当Spider发出的请求标记为需要用浏览器渲染时就调用Playwright去打开页面、等待加载完成返回渲染后的response。热词里提到的scrapyplaywright就是这个路线完整解决方案还需要考虑Playwright启动的异步事件循环和Scrapy的兼容但作为过渡方案已经够用。4.3 重复数据多、断点续爬怎么做重复数据的来源通常是两个一个是同一个商品被多个入口收录比如搜索页和列表页都包含了它另一个是重跑爬虫时没有清空上次的去重队列。Scrapy默认的去重是针对同一个Spider运行过程的每次运行结束队列就清了增量爬取时旧数据会重新进入。我的解决方案分两半。数据库层面的url_hash唯一索引是第一道防线这保证了物理上不可能有重复行。第二道防线是Scrapy的请求去重如果你要跨运行保持去重状态可以用scrapy-redis的RFPDupeFilter把请求指纹存在Redis里重跑时自动跳过已经抓过的URL。如果你不想引入Redis另一个简单做法是在Spider的start_requests里先查数据库已有的url_hash集合然后过滤掉这些URL。断点续爬是一个被低估的需求Scrapy自带的JOBDIR参数可以做到scrapy crawl market_spider -s JOBDIRcrawls/market_spider设置这个参数后Scrapy会保存运行状态下次启动时可以接着上次的进度继续爬。对校园集市这种日常几十页的站点这个功能用不用其实无所谓但如果哪次你跑了上万条数据然后中断了就明白这个参数有多救命了。4.4 入库乱码与字段截断问题MySQL入库乱码十有八九是字符集没配对。建表的时候用了utf8mb4但连接字符串里还带着旧的charsetutf8或者数据库连接池配置里没指定字符集结果中文全部变成问号。我在settings.py里配置数据库连接时会明确加上charsetutf8mb4并在MySQL的connection里设置init_commandMYSQL_CONFIG { host: 127.0.0.1, port: 3306, user: root, password: your_password, database: campus_market, charset: utf8mb4, }字段截断问题则是另一类VARCHAR长度不够比如某条商品标题特别长超过255字符插入时就被数据库截断或者直接报错。我在Pipeline里会提前判断长度超标的字段做截断处理避免入库时才发现。另外description字段用TEXT但TEXT最大只能存65535字节足够用了如果遇到超长描述做摘要存储即可。4.5 收录数据量远少于预期问题可能出在哪爬虫跑完一看网站上有500条数据我库里只有200条这种问题我遇到过好几次。老手排查的顺序是先看日志里有没有异常状态码再看选择器返回的列表长度再看是不是页面结构有分页之外的加载逻辑。最常见的原因有三个。第一选择器写错这个用scrapy shell测试就能验证。第二页面其实存在“按板块分类”的逻辑你只爬了默认板块。第三商品列表不是一次性加载完的可能滚动到底部才触发加载更多这时候要么找接口要么用Playwright模拟滚动。我建议从一开始就在Spider里加一个简单统计每页解析到的条目数、成功入库数、失败数打印到日志里。数据量大不大一跑就知道哪个环节丢了。4.6 常见问题速查表症状排查方向通常解法所有请求返回403UA/Referer/Cookie再到IP轮换UA、补请求头、降并发列表页能打开但解析不到数据JS渲染或iframeF12找接口或用Playwright重复数据多URL去重失效/数据库无唯一键加url_hash唯一索引用Redis去重中文乱码字符集不匹配建表和连接都换utf8mb4入库字段截断VARCHAR长度不足提前截断或换TEXT收录数量少分页/板块/懒加载看日志统计找遗漏入口运行中途崩了目标站反爬/自身异常加JOBDIR断点续爬5. 可复用的扩展路线与我的实操心得5.1 单机爬虫升级Scrapy-Redis的时机热词里提到了scrapy-redis这是一个非常经典的扩展核心价值是把爬虫的调度器和去重队列从单机内存搬到Redis里让多台机器可以共同消费同一个URL队列。但我想说校园集市这个体量绝大多数情况下用不上分布式。我自己测试过单机跑校园集市一天抓一万条数据轻轻松松而校园集市全站可能也就几千条商品。什么时候才需要Scrapy-Redis当你的爬虫数量上来了比如同时爬10个学校、每个站点每天几万条更新单机调度器和去重队列会成为瓶颈而且一台机器挂了整个任务就断了。这时候用Scrapy-Redis多台服务器分担压力队列在Redis里不会丢。另外如果你需要多个Spider共享去重状态比如A爬虫和B爬虫爬的是同一个站点的不同板块不希望重复抓同一个商品Redis去重也比分库分表简单。落地时改动不大settings里加几行配置把scheduler换成RedisSchedulerdupefilter换成RFPDupeFilter再指定Redis连接地址就行。唯一要注意的是Redis里存的请求指纹会越来越多需要定期清理或者设置过期策略。5.2 爬虫数据要变成可用服务还差哪几步爬虫只是数据链路的前半段数据到库里了得让用户能用起来才算完成。我的项目后期加了一个简单的搜索接口用Flask起了一个HTTP服务查询逻辑很简单商品标题做模糊匹配发布时间倒序排列。后面又给接口加了分页和价格区间筛选前端是一个极简的HTML页面输入关键词就能列出最新的二手信息。再往后我还做了一件比较有意思的事把每天新增的商品抓完后自动生成一份“今日校园二手行情摘要”统计当天发布的商品数、热门类目、价格分布推送到我的个人邮箱。这个功能实现起来不复杂就是定时任务调爬虫抓完跑一段SQL做统计然后用smtplib发邮件。但就是这个看起来不起眼的扩展让爬虫从“一次性采集工具”变成了“持续运行的小服务”也把整个项目的价值感提升了一个档次。5.3 我踩过的坑和现在的做法最后分享几个我现在固定在用的习惯。第一所有字段解析都写容错get不到就赋空值绝不让一个字段解析异常导致整条Item丢失。第二每次爬完跑一遍对账SQL比如SELECT COUNT(*)对比来源站点商品数和数据库数发现差太多立刻查日志。第三爬虫代码写完之后先用scrapy parse命令挂在目标URL上跑通了解析逻辑再正式启动全量爬取这个习惯帮我避掉了至少一半的返工。另外一个很重要的观念爬虫项目运行时间越长越要重视运行状态的监控。我现在会在Pipeline里埋一个进度计数器每处理100条Item打印一次统计配合LOG_LEVEL设置为INFO实时观察爬虫运行状态。遇到站点改版导致解析失效时一天之内就能发现问题而不是等用户反馈了才知道。这个项目从最初的一个简单爬虫脚本到后来能稳定增量更新、有搜索接口、有行情摘要的小系统前前后后跑了快两个月。最深的体会是爬虫项目的难点从来不在于把网页数据抓下来而在于数据抓下来之后怎么清洗得干净、怎么存得合理、怎么不重不漏、怎么持续稳定运行。如果你也是拿这个题目练手建议先把Item设计和Pipeline这块做扎实数据结构设计对了后面的扩展才不至于推倒重来。一个小技巧每次爬完花两分钟用SQL做一次数据量对账看起来简单但真的能帮你省下大量排查问题的时间。本文还有配套的精品资源点击获取