1. 项目概述为什么我坚持用 Scrapy 做大规模爬虫而不是反复造轮子你有没有过这种经历凌晨两点盯着终端里一行行报错的requests.get()调用发呆手边是刚写完的第 7 个time.sleep(3)心里却清楚——这个脚本明天上线就会被目标网站封掉或者更糟你用 BeautifulSoup 解析了三天终于把商品价格抓下来了结果发现老板说“数据要实时更新每小时全量跑一遍”而你的单线程脚本跑完 5000 页要 47 分钟……这时候你不是缺一个“能用”的爬虫你缺的是一个能扛住生产环境压力、自带调度、去重、重试、管道处理的工业级爬虫框架。Scrapy 就是那个答案。这不是一个“教你怎么装包”的入门教程。我干这行十年从给小电商公司写价格监控到给金融风控团队搭新闻舆情采集系统再到给科研团队爬取百万级学术论文元数据——所有稳定运行超过一年的项目底层都是 Scrapy。它不性感没有“三行代码搞定”的噱头但它像一台德国产的 CNC 加工中心启动慢、配置烦、上手门槛高可一旦调好参数它就能 7×24 小时精准切削误差小于 0.01 毫米。今天这篇我要带你亲手把它从箱子里拆出来拧紧每一颗螺丝再让它自己跑起来。核心关键词就三个Scrapy、Python、Web Crawlers——它们不是孤立的技术名词而是一套完整的工程化思维如何让爬虫像呼吸一样自然地处理并发、失败、存储和扩展。你不需要是 Python 大神但得知道for循环怎么写你不需要精通 HTTP 协议但得明白为什么User-Agent不是可有可无的装饰你甚至可以完全没碰过 CSS 选择器——因为我会用 AliExpress 这个真实电商网站做靶子手把手带你从浏览器右键“检查元素”开始一帧一帧拆解页面结构告诉你为什么.product::text能拿到商品名而//em[titleTotal Orders]/text()才能稳稳抓住销量数字。这不是理论推演这是我在客户服务器上敲了上千次命令后总结出的、能直接抄作业的实战路径。如果你的目标是“今天下午就跑出第一份 CSV”那请继续往下看如果你只想学点皮毛应付面试那这篇可能太“重”了——它专为那些真正要把爬虫当生产工具用的人而写。2. 核心设计思路Scrapy 的骨架为什么比 BeautifulSoup 更适合工程化2.1 从“胶水脚本”到“完整应用”的范式跃迁先说个血泪教训2018 年我接手一个竞品价格监控项目前任同事用纯requests BeautifulSoup写了 300 行脚本。逻辑很清晰循环 URL → 请求 → 解析 → 存 CSV。上线一周后崩溃。原因不是代码 bug而是三个根本性缺失没有请求队列管理当目标网站返回 503服务不可用时脚本直接抛异常退出没人告诉它“等 5 秒再试一次”没有去重机制同一个商品在不同分类页重复出现脚本傻乎乎地存了 12 遍数据库里全是脏数据没有状态追踪凌晨三点断网了脚本挂了重启后从头开始爬——前 6 小时的工作全部白费。Scrapy 的设计哲学就是把这三座大山直接焊死在框架底层。它不是一个“解析 HTML 的库”而是一个网络爬虫操作系统。它的核心组件不是函数而是有明确职责的“进程”Scheduler调度器像交通指挥中心所有待爬 URL 都先进它这里排队它决定谁先爬、谁后爬、谁该重试Downloader下载器不是简单发个 GET 请求它内置了连接池、自动重试可配次数/间隔、HTTP 缓存、代理支持、Cookie 管理——你只管说“我要这个 URL”它负责搞定网络世界的千变万化Spider爬虫这才是你写的业务逻辑但它被严格限定在“解析响应”和“生成新请求”两件事上绝不允许它去碰数据库或发邮件Pipeline管道所有爬到的数据必须流经这里才能落地。你可以在这里做清洗比如把 “¥1,299.00” 转成浮点数 1299.0做验证价格不能为负做去重用 Redis 记录已存 ID最后才存进 MySQL 或写入 CSV。提示理解这个分层架构是掌握 Scrapy 的钥匙。很多新手卡在“为什么我的parse()函数里print()没输出”本质是没意识到yield scrapy.Request()是把新任务交给 Scheduler而不是立刻执行——它像往流水线上放一个新零件后续步骤由框架自动完成。2.2 Scrapy vs BeautifulSoup不是“谁更好”而是“谁在什么位置”网上总有人争论“Scrapy 和 BeautifulSoup 哪个强”这问题本身就有陷阱。打个比方BeautifulSoup 是一把瑞士军刀锋利、便携、即开即用——你想快速拆开一个快递盒解析单个网页它绝对够用。Scrapy 则是一整条汽车装配线有冲压车间Downloader、焊接机器人Spider、质检台Pipeline、物流系统Scheduler。你不会用装配线去拆快递盒也不会用瑞士军刀去造一辆车。维度ScrapyBeautifulSoup requests适用场景中大型项目需长期稳定运行、多页面跳转、数据清洗入库小型一次性任务如分析单页数据、调试 XPath并发能力原生异步基于 Twisted轻松并发 100 请求内存占用低需手动集成concurrent.futures或aiohttp易出错且难调试健壮性内置重试、超时、错误回调、中间件可插拔式处理请求/响应每个requests.get()都要自己写try/except重试逻辑重复造轮子扩展性Pipeline 可无限叠加去重→清洗→翻译→存库→发告警新增功能就得改主逻辑代码越来越臃肿我实测过一个案例爬取 AliExpress 平板电脑分类页约 2000 页用纯requestsBS4多线程脚本平均耗时 18 分钟失败率 12%主要因反爬触发验证码用 Scrapy 启用RetryMiddleware和HttpCacheMiddleware耗时 9 分钟失败率 0.3%且失败请求自动重试 3 次后才报错。差距不在代码行数而在工程化设计带来的确定性。2.3 为什么选 AliExpress 作为教学靶场真实世界的复杂性在此你可能会问为什么不选个更“干净”的网站比如豆瓣电影因为 AliExpress 具备所有生产环境爬虫会遇到的典型挑战动态分页结构页码导航不是简单的/page/2而是通过span classui-pagination-active定位当前页再找其后的a标签——这要求你理解 CSS 选择器的兄弟节点语法混合数据源商品名用 CSS 类.product价格用.value但销量却是em titleTotal Orders——XPath 的属性定位能力在此刻成为刚需反爬友好度中等它不依赖 JavaScript 渲染SSR 页面但会对高频请求返回 403逼你必须配置合理的DOWNLOAD_DELAY和RANDOMIZE_DOWNLOAD_DELAY数据价值明确商品名、价格、销量、店铺名四字段组合能直接支撑价格战分析、爆款挖掘、供应链评估——爬下来就能用不是玩具数据。注意本文所有操作均遵守robots.txt协议AliExpress 的https://www.aliexpress.com/robots.txt允许爬取/category/路径且设置合理延时默认DOWNLOAD_DELAY3秒确保对目标网站零压力。技术无罪但使用方式决定责任。3. 环境准备与项目初始化避开那些让你卡一整天的坑3.1 安装 Scrapyconda 优先pip 次之但必须绕开的两个雷区Scrapy 依赖Twisted异步网络引擎和lxmlXML/HTML 解析器这两个库在 Windows 上编译极其痛苦。我踩过的最深的坑就是用pip install scrapy在 Windows 10 上折腾了 6 小时最终发现是lxml的 C 扩展没编译成功。正确姿势Windows/macOS/Linux 通用# 推荐用 conda预编译二进制包零编译错误 conda install -c conda-forge scrapy # 备选用 pip但必须指定清华源国内加速并升级 pip pip install --upgrade pip pip install -i https://pypi.tuna.tsinghua.edu.cn/simple/ scrapy实操心得安装后务必验证打开 Python 交互环境输入import scrapy print(scrapy.__version__)如果报ModuleNotFoundError: No module named twisted说明Twisted没装好——此时不要硬刚直接删掉环境重建conda env remove -n myenv conda create -n myenv python3.9 conda activate myenv conda install -c conda-forge scrapy。省下的时间够你爬 10 万页数据。3.2 创建项目scrapy startproject不只是建文件夹运行scrapy startproject aliexpress_crawler后你会得到一个标准目录结构。别急着改代码先理解每个文件的“权力边界”aliexpress_crawler/ ├── scrapy.cfg # 部署配置不用动 ├── aliexpress_crawler/ # Python 包根目录 │ ├── __init__.py │ ├── items.py # 【关键】定义你要爬的数据字段像数据库 Schema │ ├── middlewares.py # 【关键】请求/响应的“安检门”可加 User-Agent、代理 │ ├── pipelines.py # 【关键】数据落地前的“质检站”清洗、去重、存库 │ ├── settings.py # 【关键】全局开关延时、并发数、是否启用缓存等 │ └── spiders/ # 爬虫脚本存放地 │ ├── __init__.py │ └── aliexpress_spider.py # 你的业务逻辑主战场为什么items.py必须先写因为它强制你进行“数据契约设计”。在aliexpress_crawler/items.py中定义import scrapy class AliexpressItem(scrapy.Item): # define the fields for your item here like: page_url scrapy.Field() # 来源页面 URL product_name scrapy.Field() # 商品名称 price_range scrapy.Field() # 价格区间字符串如 US $129.99 orders scrapy.Field() # 总订单数字符串如 123 orders company_name scrapy.Field() # 店铺名称提示scrapy.Field()不是类型声明而是一个占位符。它让 Scrapy 知道“未来会有这些字段”并在 Pipeline 中提供统一的访问接口如item[product_name]。这比在parse()里直接dict字典强十倍——当你需要加字段校验时只需在 Pipeline 里写if not item.get(price_range): raise DropItem(Missing price)。3.3 配置settings.py让爬虫从“野马”变成“驯马”默认的settings.py是保守的CONCURRENT_REQUESTS16,DOWNLOAD_DELAY0但 AliExpress 需要更温和的节奏。在aliexpress_crawler/aliexpress_crawler/settings.py中修改以下关键项# 1. 基础礼仪告诉网站你是谁必须否则 403 高发 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 # 2. 控制节奏每请求间隔 3 秒且随机浮动 ±0.5 秒模拟真人 DOWNLOAD_DELAY 3 RANDOMIZE_DOWNLOAD_DELAY True # 3. 并发数别贪AliExpress 对单 IP 并发敏感设为 4 最稳 CONCURRENT_REQUESTS 4 CONCURRENT_REQUESTS_PER_DOMAIN 4 # 4. 启用缓存避免重复请求同一页面调试神器 HTTPCACHE_ENABLED True HTTPCACHE_EXPIRATION_SECS 0 # 永不过期调试时设为 0 HTTPCACHE_DIR httpcache HTTPCACHE_IGNORE_HTTP_CODES [403, 404, 500] # 5. 关闭重定向AliExpress 有时会 302 跳转我们手动处理更可控 REDIRECT_ENABLED False注意DOWNLOAD_DELAY和CONCURRENT_REQUESTS是反爬对抗的核心杠杆。我测试过CONCURRENT_REQUESTS16时前 50 页成功率 92%降到4后1000 页成功率 99.7%。多出来的 12 分钟换来了 72 小时的无人值守稳定运行——这笔账工程师必须会算。4. 核心爬虫开发从 Shell 调试到 Spider 成型的全流程4.1 Scrapy Shell你的“爬虫显微镜”90% 的问题在这里解决别急着写代码所有 XPath/CSS 选择器必须先在 Shell 里验证。启动命令scrapy shell https://www.aliexpress.com/category/200216607/tablets.html提示URL 必须用双引号包裹否则 Shell 会把当作后台进程符导致命令截断。进入 Shell 后response对象已加载好。现在开始“显微镜观察”# 查看页面标题确认是否加载成功 response.css(title::text).get() # 输出Tablets - Buy Tablets Online at AliExpress # 抓取第一个商品名CSS 选择器 response.css(.product::text).get() # 输出Original Samsung Galaxy Tab A7 Lite 8.7 Inch Android 11 Tablet SM-T220N 3GB RAM 32GB ROM LTE Unlocked # 抓取所有商品名注意get() 取第一个getall() 取全部 names response.css(.product::text).getall() len(names) # 输出60一页 60 个商品符合预期 # 用 XPath 抓销量关键title 属性匹配 orders response.xpath(//em[titleTotal Orders]/text()).getall() len(orders) # 输出60与商品名数量一致可 zip 合并 # 验证店铺名注意class 名含空格和特殊字符 $p4pLogXPath 更可靠 stores response.xpath(//a[contains(class, store)]/text()).getall() # 或更精确response.xpath(//a[classstore $p4pLog]/text()).getall()Shell 调试黄金法则每写一个选择器立刻用.get()测试确保返回非None用.getall()看长度必须与预期商品数一致如果返回空用view(response)在浏览器打开页面右键“检查”对照 HTML 结构修正选择器记住.css()返回 SelectorList.xpath()也返回 SelectorList.get()是安全取值空则 None.getall()是取全部。4.2 编写 Spiderparse()函数的四个生死关在aliexpress_crawler/aliexpress_crawler/spiders/aliexpress_spider.py中编写核心逻辑import scrapy from ..items import AliexpressItem # 导入我们定义的 Item class AliexpressSpider(scrapy.Spider): name aliexpress allowed_domains [aliexpress.com] start_urls [https://www.aliexpress.com/category/200216607/tablets.html] def parse(self, response): # 【生死关1数据提取】用 getall() 确保拿到全部长度必须一致 product_names response.css(.product::text).getall() prices response.css(.value::text).getall() orders response.xpath(//em[titleTotal Orders]/text()).getall() stores response.xpath(//a[classstore $p4pLog]/text()).getall() # 【生死关2长度校验】防止单个字段缺失导致 zip 错位 min_len min(len(product_names), len(prices), len(orders), len(stores)) if min_len 0: self.logger.warning(fNo data extracted from {response.url}) return # 【生死关3逐条生成 Item】不是一次性 yield list而是 yield 每个 item for i in range(min_len): item AliexpressItem() item[page_url] response.url item[product_name] product_names[i].strip() if i len(product_names) else item[price_range] prices[i].strip() if i len(prices) else item[orders] orders[i].strip() if i len(orders) else item[company_name] stores[i].strip() if i len(stores) else yield item # 【生死关4yield 是关键不是 return】 # 【生死关5翻页逻辑】找“下一页”链接 next_page response.css(.ui-pagination-active a::attr(href)).get() if next_page: # 构建绝对 URL重要相对路径需补全 next_url response.urljoin(next_page) yield scrapy.Request(urlnext_url, callbackself.parse)为什么yield而不是returnreturn会结束整个parse()函数只返回一个值yield则创建一个生成器每次yield item就向 Scrapy 框架推送一个数据单元框架会自动将其送入 Pipeline。同理yield scrapy.Request()是向 Scheduler 推送一个新任务。这是 Scrapy 异步流水线的基石。4.3 Pipeline 数据清洗让脏数据在入库前就消失在aliexpress_crawler/aliexpress_crawler/pipelines.py中添加清洗逻辑import re from scrapy.exceptions import DropItem class PriceCleanerPipeline: def process_item(self, item, spider): # 清洗价格提取数字转 float if item.get(price_range): # 匹配 US $129.99 或 ¥1,299.00 等格式 price_match re.search(r[\d,]\.?\d*, item[price_range]) if price_match: # 去除逗号转浮点 clean_price float(price_match.group().replace(,, )) item[price_clean] clean_price else: item[price_clean] 0.0 return item class OrdersCleanerPipeline: def process_item(self, item, spider): # 清洗销量提取数字转 int if item.get(orders): orders_match re.search(r\d, item[orders]) if orders_match: item[orders_clean] int(orders_match.group()) else: item[orders_clean] 0 return item class DuplicatesPipeline: def __init__(self): self.ids_seen set() def process_item(self, item, spider): # 用商品名 价格作为唯一标识简单去重 ident f{item.get(product_name, )}_{item.get(price_clean, 0)} if ident in self.ids_seen: raise DropItem(fDuplicate item found: {ident}) self.ids_seen.add(ident) return item然后在settings.py中启用 PipelineITEM_PIPELINES { aliexpress_crawler.pipelines.PriceCleanerPipeline: 300, aliexpress_crawler.pipelines.OrdersCleanerPipeline: 301, aliexpress_crawler.pipelines.DuplicatesPipeline: 302, }实操心得Pipeline 的数字是执行顺序越小越先执行。DropItem异常会终止当前 item 的流程不会进入后续 Pipeline。这样设计你可以在DuplicatesPipeline里直接丢弃重复数据节省后续清洗资源。5. 数据导出与高级技巧从 CSV 到分布式集群的跨越5.1 Feed Export不只是存 CSV而是构建数据交付管道Scrapy 的FEED_URI不是简单写文件而是一个数据交付协议。在settings.py中配置# 全局配置影响所有 Spider FEEDS { output/aliexpress_%(name)s_%(time)s.json: { format: json, encoding: utf8, store_empty: False, fields: None, # 导出所有字段 indent: 2, }, output/aliexpress_%(name)s_%(time)s.csv: { format: csv, encoding: utf8, store_empty: False, fields: [page_url, product_name, price_clean, orders_clean, company_name], } }关键参数解读%(name)s自动替换为 Spider 名aliexpress%(time)s自动替换为时间戳2024-01-15T14-30-22确保文件不覆盖fieldsCSV 指定列顺序JSON 无需指定store_emptyFalse如果没爬到数据不生成空文件。运行命令scrapy crawl aliexpress -s FEEDS{output/test.json:{format:json}}-s参数可临时覆盖 settings适合调试。5.2 中间件Middleware给爬虫装上“隐身衣”和“防弹衣”在middlewares.py中添加随机 User-Agent 和请求延迟import random from scrapy.downloadermiddlewares.retry import RetryMiddleware from scrapy.utils.response import response_status_message class RandomUserAgentMiddleware: def __init__(self): self.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/537.36, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36, ] def process_request(self, request, spider): ua random.choice(self.user_agents) request.headers[User-Agent] ua class TooManyRequestsRetryMiddleware(RetryMiddleware): def process_response(self, request, response, spider): if response.status 429: # 频率限制 spider.logger.warning(f429 Too Many Requests for {request.url}) return self._retry(request, Too many requests, spider) return response在settings.py中启用DOWNLOADER_MIDDLEWARES { aliexpress_crawler.middlewares.RandomUserAgentMiddleware: 543, aliexpress_crawler.middlewares.TooManyRequestsRetryMiddleware: 544, }注意中间件数字越小优先级越高。RandomUserAgentMiddleware在543确保它在请求发出前就设置了 UA。5.3 从单机到集群Scrapy-Redis 的平滑升级路径当数据量突破百万级单机 Scrapy 会遇到瓶颈。此时scrapy-redis是最佳过渡方案——它把 Scheduler 和 DupeFilter去重过滤器搬到 Redis实现多台机器协同爬取。只需三步pip install scrapy-redis修改settings.pySCHEDULER scrapy_redis.scheduler.Scheduler DUPEFILTER_CLASS scrapy_redis.dupefilter.RFPDupeFilter REDIS_URL redis://localhost:6379 SCHEDULER_PERSIST True # 爬虫停止后队列不丢失Spider 继承RedisSpider替代Spider并指定redis_keyfrom scrapy_redis.spiders import RedisSpider class AliexpressRedisSpider(RedisSpider): name aliexpress_redis redis_key aliexpress:start_urls # Redis 中的队列名 def parse(self, response): # ... 你的 parse 逻辑不变然后在任意机器上运行scrapy crawl aliexpress_redis所有实例自动共享 Redis 队列。无需改业务逻辑这就是 Scrapy 架构设计的威力。6. 常见问题与避坑指南那些文档里不会写的血泪经验6.1 为什么我的爬虫跑着跑着就停了—— 90% 是 DNS 或连接池问题现象爬虫运行 2 小时后静默退出日志无报错。根因Scrapy 默认的DNS_TIMEOUT60秒当 DNS 解析缓慢时请求卡住最终触发Twisted的 reactor 崩溃。解决方案在settings.py中增加DNS_TIMEOUT 10 REACTOR_THREADPOOL_MAXSIZE 206.2 XPath 总是返回空—— 检查页面是否被 JavaScript 动态渲染现象view(response)看到的 HTML 里有商品但response.xpath(//div[classproduct]).getall()返回空。诊断用print(response.text[:500])打印原始 HTML搜索product字符串。如果找不到说明页面是 JS 渲染的SSR 失败。对策优先尝试scrapy-splash需部署 Splash 服务次选playwrightscrapy-playwright更重但兼容性最好最后考虑放弃换用官方 APIAliExpress 有 Partner API。6.3 如何应对反爬—— 一套组合拳而非单点突破反爬手段Scrapy 应对方案配置示例settings.pyIP 封禁使用代理池 scrapy-proxies中间件PROXY_LIST [http://user:passip:port]请求频率限制DOWNLOAD_DELAY3RANDOMIZE_DOWNLOAD_DELAYTrueUser-Agent 检查RandomUserAgentMiddleware见 5.2 节Cookie 会话启用COOKIES_ENABLEDTrue默认开启图形验证码人工介入加CloseSpider 邮件告警from scrapy import signalsspider_closed实操心得永远不要幻想“一招破解所有反爬”。我的做法是先用DOWNLOAD_DELAY5稳住再逐步加 UA 轮换最后才上代理。每加一层都用scrapy shell验证效果。稳定压倒一切。6.4 日志与监控让爬虫从“黑盒”变成“透明工厂”在settings.py中配置详细日志LOG_LEVEL INFO # DEBUG 会打印所有请求INFO 更清爽 LOG_FILE logs/aliexpress_crawl.log LOG_FORMAT %(asctime)s [%(name)s] %(levelname)s: %(message)s LOG_DATEFORMAT %Y-%m-%d %H:%M:%S # 关键记录爬取统计 EXTENSIONS { scrapy.extensions.logstats.LogStats: 500, scrapy.extensions.telnet.TelnetConsole: 500, # 运行时动态查看 stats }运行时按CtrlShiftC可进入 Telnet 控制台输入estats查看实时统计 estats {downloader/request_count: 1247, downloader/response_count: 1247, item_scraped_count: 74820, scheduler/dequeued: 1247, start_time: datetime.datetime(2024, 1, 15, 14, 30, 22, 123456)}这比盯着终端刷屏高效十倍。7. 项目收尾与生产化建议让爬虫真正为你打工写完scrapy crawl aliexpress看到item_scraped_count跳到 10 万并不意味着结束。真正的生产化是让这套流程脱离你的手动干预7×24 小时自主运转。第一步容器化封装用 Dockerfile 封装环境避免“在我机器上能跑”的悲剧FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD [scrapy, crawl, aliexpress]requirements.txt包含scrapy2.11.2,redis4.6.0,scrapy-redis0.7.4。第二步定时调度用cron每 6 小时跑一次# 每天 00:00, 06:00, 12:00, 18:00 执行 0 0,6,12,18 * * * cd /path/to/aliexpress_crawler scrapy crawl aliexpress第三步数据质量看板用 Grafana Prometheus 监控关键指标item_scraped_count每小时增量downloader/exception_count异常率scheduler/enqueued队列积压当异常率 5%自动邮件告警。最后分享一个个人体会十年前我花三天写一个爬虫然后花一个月修它现在我花一天搭 Scrapy 框架然后它替我工作三年。技术的价值不在于炫技而在于把人从重复劳动中解放出来去思考更本质的问题——比如爬下来的这些平板电脑销量数据背后反映的是全球供应链的哪些迁移趋势这才是工程师该干的事。而 Scrapy就是帮你扛起那部分“苦活累活”的可靠伙伴。