以前做采集任务，我习惯一个网站建一个Scrapy工程，时间一长，机器上躺了好几个结构几乎一样的爬虫项目：同一个数据库连接、同一份清洗逻辑、同一套代理重试，每次改公共的东西都得挨个复制粘贴，改一遍就是半天。最近接到一个更实际的需求——不光要同时爬不同的网站，每个网站底下还要按不同的站点栏目去抓，比如资讯站分时政、科技、财经几个频道，每个频道页面模板还不完全一样。这种时候再搞"一网站一工程"就是给自己挖坑。
我把所有采集目标收敛进了一个Scrapy项目，用一个工程同时调度多个spider，在spider内部再按站点规则做分流，最终统一走一套Pipeline落库。这套架构跑下来，新增一个采集源基本只需要加一个文件，公共逻辑全复用。这篇就把整个做法的骨架设计、规则编排、管道分流、并发调度和踩坑过程完整拆一遍，写给正在被多目标站、多栏目采集折磨的爬虫工程师参考。
1. 为什么要合并：单工程多spider的收益与适用边界
1.1 多工程分散维护的真实成本
很多人对Scrapy的第一反应就是"一个项目一个爬虫"，这个思路在小规模验证阶段没毛病，但一旦目标网站数量超过两三个，问题就暴露得特别明显。
我举个例子。你为网站A建了一个工程，为网站B又建了一个工程，两个工程里的数据库连接、日志配置、User-Agent池、重试中间件，90%都是复制粘贴。结果某天发现连接池需要加一个参数，你得在两个工程里同步改；某天一篇文章存库前需要统一做关键词过滤，又是两处都得动。更麻烦的是，每个工程要单独部署、单独看日志、单独维护依赖版本，光是把库升个级都能折腾出顺序差异。
这种"复制粘贴式维护"在采集源数量少的时候勉强能忍，一旦目标站清单扩展到十几个，你花在工程间切换和重复配置上的时间，会远远超过写解析规则本身。这也是我做这次重构的第一动力：把"配置"和"规则"分离，规则可以每个站点一套，但配置、调度、存储、监控必须共享。
1.2 合并后的收益与不该合并的场景
合并成一个Scrapy项目后，收益非常直接：
- 公共代码只维护一份，包括Item定义、Pipeline、代理中间件、数据库工具类；
- 只需要在一个虚拟环境里管理依赖版本，部署变成一个目录走天下；
- 可以一次性
scrapy crawl site_a site_b site_c批量启动，日志按spider分离，整个采集链路都在同一个视图里； - 新增采集源时，只需要在spiders目录下加一个文件，再在配置里声明好运行参数，不用动任何公共代码。
但有两点我需要提前泼冷水。第一，如果两个采集源的数据最终落到完全不同的业务系统，且清洗逻辑几乎不重叠，那强行合并反而让Pipeline里堆满if-else，这种场景保持独立工程更清晰。第二，如果某个采集源的数据量特别大、运行频率又和别的源天差地别，建议单独跑一个工程实例，便于独立扩缩容，而不是把所有源都绑死在一个项目里一起部署。
一句话总结适用边界：多个源之间共享大部分设施、只是目标页面不同，合并最划算；业务边界清晰、生命周期互相独立，拆开更省心。我这次接的需求正好属于第一种情况，所以选择了单工程多spider的架构。
2. 骨架搭法：公共模块、Item设计与爬虫级配置
2.1 目录结构里的"共享"与"隔离"
确定合并之后，第一步是设计工程目录。我的原则是：所有可复用逻辑下沉到公共模块，所有站点相关但非解析的部分放进配置项，解析规则只保留在各自的spider文件里。
my_collector/ ├── scrapy.cfg ├── requirements.txt └── my_collector/ ├── __init__.py ├── items.py ├── middlewares.py ├── pipelines.py ├── settings.py ├── spiders/ │ ├── __init__.py │ ├── news_a.py │ ├── sports_b.py │ └── travel_c.py └── utils/ ├── cleaner.py ├── db.py └── headers.py这个结构看起来简单，但里面有两条隐性规则。一是spiders目录下每个文件只做一件事：定义爬虫名、起始URL列表、链接规则、解析回调，不做任何数据加工；二是所有站点共用的数据库对象、清洗函数、请求头生成器都收进utils，避免出现"某个解析函数里直接写了个DB操作方法"这种代码垃圾。
你可能要问，为什么不按网站建子包？原因很简单：Scrapy的SPIDER_MODULES配置要求spider类能在模块路径下被自动发现。你可以在SPIDER_MODULES = ["my_collector.spiders"]下再细分，但发现机制会要求import路径对得上，徒增心智负担。十几个spider文件平铺在spiders目录下，文件名就是爬虫名，一眼就知道有哪些采集源，比嵌套目录更直观。
2.2 Item全字段设计：给每条数据打上"来源双标"
多网站多站点场景里，Item设计是整个架构的压舱石。如果每个spider各自定义自己的Item，Pipeline就没法统一处理；如果所有spider共用一个Item，就必须在字段上留足来源维度。
我在这个项目里用了统一Item结构：
class ArticleItem(scrapy.Item): # 内容字段 title = scrapy.Field() url = scrapy.Field() publish_time = scrapy.Field() content_text = scrapy.Field() author = scrapy.Field() # 来源标记字段 source_website = scrapy.Field() # 顶级网站标识，如 "news_a" source_site = scrapy.Field() # 网站内的站点/栏目，如 "politics"、"tech" site_category = scrapy.Field() # 扩展分类，可在解析时附带补充 spider_name = scrapy.Field() # 记录实际采集的spider名，方便回查为什么强调这两个来源字段？因为"同时爬不同的网站，网站内不同的站点"有两个采集维度，缺一个都无法定位一条数据到底从哪来。source_website用于区分顶级目标站，source_site用于区分网站内部的频道或子站。这两个字段一旦在spider里漏填，后续Pipeline做分站落库、去重、差异清洗时就会失去依据。
另外我建议把spider_name也放进Item。虽然Pipeline的process_item方法能拿到spider对象，但数据一旦异步写入队列或者落到下游做补偿处理时，再次识别来源的成本会很高。直接在Item里冗余一个字段，查询和排查用起来顺手得多。
2.3 公共settings与爬虫级配置的分工
settings.py是所有共享配置的控制中心，但要注意，不同网站的robots策略、下载延迟、并发要求通常是不同的，一刀切会出问题。Scrapy的配置优先级是：命令行参数 > 爬虫自定义custom_settings > 全局settings。所以我的分工方式是：
- 全局settings放适用于所有源的公共项：机器人协议、默认超时、Item Pipeline、下载中间件、日志格式；
- 每个spider内部用custom_settings覆盖自身偏好的参数，比如某个源访问压力大，就单独
DOWNLOAD_DELAY = 0.8；某个源响应快、字段轻，就单独CONCURRENT_REQUESTS = 32。
class NewsASpider(scrapy.Spider): name = "news_a" allowed_domains = ["news-a-example.com"] start_urls = ["https://news-a-example.com/"] custom_settings = { "DOWNLOAD_DELAY": 0.3, "CONCURRENT_REQUESTS": 16, "RETRY_TIMES": 2, }这种做法能避免一个常见的误伤场景：某个网站的服务器响应很慢，你又不想给所有采集源都加上高延迟；或者某个网站的页面结构简单，本来可以高并发快抓，却被全局的低并发参数拖了效率。爬虫级配置就是为这种"同类工程、不同节奏"准备的。
3. "网站内又有站点"的解析编排：规则分流与回调传参
3.1 单Spider多入口的两种写法
同一个网站内的不同站点，最粗暴的做法是给每个站点都写一个spider。这种做法的坏处很明显：如果这些站点结构类似、字段相似，你会得到一大批只差一个路径前缀的spider文件，等于把同一份解析逻辑复制了好几遍。
更好的做法是：一个域名下，凡是用同一套下载策略和字段映射的站点，尽量收敛到一个spider里，通过起始URL列表或链接规则区分。我在项目里常用两种写法。
第一种：用start_urls列出多个站点入口，在同一个parse里通过URL特征判断当前属于哪个站点，再填充Item的source_site。这个方案适合页面结构高度统一的站点，代码最省，但站点一旦增多，parse里全是一长串if-elif判断URL前缀，可读性下降明显。
第二种：用cb_kwargs把站点标识直接传给回调函数，让每个站点有独立的解析入口。这个方案在维护性和可读性上明显优于第一种，也是我下面重点讲的做法。
3.2 CrawlSpider多Rules的正确打开方式
网站内不同站点往往有独立的目录路径，比如/politics/、/tech/、/sports/。用CrawlSpider时，我会为每个站点写一条Rule，每条Rule指定当前站点的详情页链接匹配模式，并在回调里通过cb_kwargs把站点标识传进去。
class NewsASpider(CrawlSpider): name = "news_a" allowed_domains = ["news-a-example.com"] start_urls = [ "https://news-a-example.com/politics/", "https://news-a-example.com/tech/", "https://news-a-example.com/health/", ] rules = ( Rule( LinkExtractor(allow=r"/politics/\d+\.html"), callback="parse_detail", cb_kwargs={"site_tag": "politics"}, ), Rule( LinkExtractor(allow=r"/tech/\d+\.html"), callback="parse_detail", cb_kwargs={"site_tag": "tech"}, ), Rule( LinkExtractor(allow=r"/health/\d+\.html"), callback="parse_detail", cb_kwargs={"site_tag": "health"}, ), Rule( LinkExtractor(allow=r"/politics/page-\d+"), follow=True, ), ) def parse_detail(self, response, site_tag): item = ArticleItem() item["source_website"] = "news_a" item["source_site"] = site_tag item["url"] = response.url item["title"] = response.css("h1::text").get() return item这里有三处细节值得说清楚。
cb_kwargs是Scrapy内置的参数传递机制，它会以关键字参数形式传给回调函数。比起在回调里写正则去重新匹配URL，这种显式传参的方式既清晰又不容易错。特别是URL里如果同时包含多个关键词，或者路径经过了改写，靠字符串匹配极容易翻车，显式传参不存在这个问题。
Rules的顺序有讲究。CrawlSpider从页面提取链接时，是按照Rules元组顺序逐个匹配的，先命中哪个就用哪个。如果你把"站点A的详情页规则"放到了"通用列表页规则"后面，详情链接就可能被那个通用规则当成普通链接直接follow掉，根本不进parse_detail。所以列表页规则要放在所有详情页规则之后，并且尽量用restrict_xpaths缩小链接提取范围。
follow=True的规则只负责翻页链接，不设callback。很多人会问，为什么翻页链接规则不写callback？因为在CrawlSpider里，一个链接同时匹配多条Rule时，优先级行为会变复杂。对于翻页链接，我们需要的是递归提取下一页里的新链接，而不是把下一页本身当成详情页解析，所以单独给翻页规则设follow=True即可，不需要回调。
3.3 回调传参常见翻车现场
我在重构时踩过一个很典型的坑：给多个站点都用了同一个parse_detail，但一开始没传site_tag，而是直接在函数内部用response.url去正则匹配站点路径。结果网站更新了URL结构，把原本干净的/politics/123.html改成了带中间层级的/news-list/2024/politics/123.html，我的正则一口气匹配不到，好几天的数据source_site字段全是None，落库后分站统计全乱套。
后来我把所有站点标识都改成通过cb_kwargs显式传入，解析函数里不再依赖URL字符串猜测站点归属。好处是URL怎么变都不影响字段正确性，坏处是新增站点时要记得加一条Rule和对应的callback参数。从长期维护看，显式传参的可靠性远超"在解析时猜来源"。
另外要注意，cb_kwargs传入的值会原样冻结在request的meta里。如果某个字段是动态生成的，比如session信息，不能指望它在回调里实时变化。这个我们需要的是静态的站点标签，冻结反而更安全。
4. Pipeline按来源分流：让不同站点的数据走不同加工链路
4.1 基于spider.name或Item字段的管道分流
不同网站抓下来的数据，字段往往不能直接通用：有的站发布时间是时间戳，有的是2024-05-20格式，有的是相对时间"3小时前"；有的站正文里带大量HTML标签，有的已经干净得可以直接入库。这些差异不适合在每个spider里各写一套清洗逻辑，统一放进Pipeline里按来源分流才是正解。
Pipeline的process_item(self, item, spider)方法天然接收两个参数，其中spider.name就是当前spider的唯一标识。我通常在每个管道的第一步做分流判断：
class ContentCleanPipeline: def process_item(self, item, spider): if spider.name == "news_a": item["publish_time"] = self.parse_news_a_time(item.get("publish_time")) item["content_text"] = self.clean_html(item.get("content_text")) elif spider.name == "sports_b": item["publish_time"] = self.parse_sports_b_time(item.get("publish_time")) return item这里有一个容易被忽略的细节：Pipeline分流也可以用Item字段而不是spider.name。如果你把source_site作为分流依据，那就要求每个spider都严格填写这个字段，一旦漏填，数据就会掉进默认分支，表现就是那个站点的数据在最终库里缺失或清洗不符。我的习惯是：顶层分站用spider.name，因为它不可能为空；站内差异用source_site，用的时候必须有兜底逻辑。
4.2 重复过滤与内容清洗的分层设计
多源采集必然面临重复数据问题。同一个网站里，不同栏目页面可能指向同一篇文章；不同网站之间，也可能出现转载相同内容的情况。我的Pipeline分层大致如下：
100：DuplicateFilterPipeline（按站点+URL去重） 200：ContentCleanPipeline（按来源清洗处理HTML和格式） 300：NormalizePipeline（公共字段标准化、生成数据指纹） 400：StoragePipeline（写入数据库）去重管道要注意指纹范围。如果只按url去重，那么同一个源的两条spider同时抓同一个URL时会误伤；如果不加来源维度，跨站同URL这种极小概率事件会影响全库。我一般用sha1(source_website + "|" + source_site + "|" + url)作为指纹key，存在Redis里做全局判重。为什么用Redis而不是直接查数据库？因为高并发场景下每条item都去查一次库，连接开销和查询延迟都受不了，Redis的SETNX既能保证原子性又足够快。
内容清洗管道最常踩的坑是"以为每个站的HTML结构都稳定"。我以前为某个站写好了正文提取XPath，结果对方改版后正文摘要全变了，清洗出来的内容一段空白。后来我在清洗管道里加了字段完整度检查：如果content_text长度低于阈值，宁可在日志里打WARN并保留原文，也不做二次截断。少一条带原文的数据，总好过存一条被误清成空壳的垃圾数据。
4.3 落库策略与分表/分区思路
数据落库时，因为同时有"网站"和"站点"两个维度，表结构设计需要提前想清楚。我推荐的做法是：物理上一张article表，逻辑上通过source_website和source_site字段做分区或查询索引。不要为每个站点单独建表，那样一旦新增站点就要跑DDL，运维成本极高，查询多个站点时还得UNION ALL，效率也差。
CREATE TABLE article ( id BIGINT AUTO_INCREMENT PRIMARY KEY, source_website VARCHAR(32) NOT NULL, source_site VARCHAR(32) NOT NULL, title VARCHAR(255), url VARCHAR(255) UNIQUE, publish_time DATETIME, content LONGTEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_website_site (source_website, source_site) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;数据库连接池可以多个spider共享，但要注意不要在每条item里新建连接。这是我见过的最常见的低效写法——每个item处理时pymysql.connect()一次，采集量稍微一大连接数就把数据库端口打满。正确做法是在Pipeline的open_spider里建立连接，在close_spider里关闭，或者用连接池对象，整个spider生命周期复用。
5. 并行调度与日志隔离：别让一个慢站点拖垮全队
5.1 并发模型的误区和合理参数
你可能以为CONCURRENT_REQUESTS = 64是全局并发上限，实际不是。Scrapy的调度器是按spider实例独立的，每个spider拥有自己的请求队列和连接池。也就是说，同时跑三个spider，每个spider各自允许64个并发请求，总并发可能高达192。这个"乘数效应"是并行调度里第一个需要心里有数的点。
不同网站的响应速度差异极大。某个技术博客响应时间可能只要150ms，另一个老旧的新闻门户遇到并发稍微高一点就开始丢连接。如果给所有spider都配同样的高并发，后者会把大量请求时间消耗在超时重试上，白白浪费线路资源。所以每个spider的custom_settings里，我会根据目标站的实际情况单独配置CONCURRENT_REQUESTS和DOWNLOAD_DELAY。
AutoThrottle是个被很多人低估的配置。它可以根据目标站的响应时间自动调节下载速度，让爬虫对慢站点更温柔，对快站点更高效。我的建议是全局开启AUTOTHROTTLE_ENABLED = True，并设置保守的初始延迟：
AUTOTHROTTLE_ENABLED = True AUTOTHROTTLE_START_DELAY = 1.0 AUTOTHROTTLE_MAX_DELAY = 10.0 CONCURRENT_REQUESTS_PER_DOMAIN = 8需要注意，AutoThrottle和手动设置的DOWNLOAD_DELAY存在冲突关系。如果你在某个spider里已经明确指定了固定的下载延迟，那AutoThrottle的自动调节会优先作用于当前的爬行行为，实际情况以我的经验，固定配置个0.3到0.5更可控。开启这个配置前，最好先小批量试跑，看目标站的容忍度。
5.2 超时、重试与慢站点拖累问题
多spider并行时最典型的问题是：某个站的DNS解析慢、连接迟迟不建立、超时一直拖到30秒才返回。这种慢请求虽然不占用其他spider的并发槽位，但会占住这个spider自己的请求队列和等待回调的上下文，导致这个站点的整体吞吐量骤降。
我给所有spider统一设置了DOWNLOAD_TIMEOUT = 20，并把重试次数降为1。如果20秒内连不上，说明目标站的网络链路有问题，继续重试也大概率还是失败，不如把槽位让给正常请求。再配合RETRY_HTTP_CODES排除掉一部分不需要重试的编码，能明显减少无意义的等待。
这里有一个取舍：重试次数设得越少，单个请求失败率会升高，但整体的爬取完成时间更稳定。如果你的采集任务允许"今天漏一点、明天再补"，低重试策略是最优解；如果必须当天全量抓完，那可以适当提高重试，但需要单独的失败补偿机制，而不是无限在调度器里重试。
5.3 日志分离与运行监控
多个spider同时跑的时候，日志混在一个终端里几乎没法看。我用的方案是启动时给每个spider单独指定日志文件：
scrapy crawl news_a --logfile logs/news_a.log --loglevel INFO scrapy crawl sports_b --logfile logs/sports_b.log --loglevel INFO scrapy crawl travel_c --logfile logs/travel_c.log --loglevel INFO如果不想手动开三个终端，也可以写个启动脚本后台拉起，每个spider独立进程，互不影响。这里要提醒一句：Scrapy 2.x支持一次性启动多个spider，scrapy crawl news_a sports_b，但所有spider共用一份LOG_FILE配置，日志会混在一起。如果需要分文件记录，我建议还是分别启动进程，或者用扩展在spider维度重定向日志输出。
监控层面，我给项目加了信号回调：监听item_scraped和spider_error，把每个spider的抓取成功数、失败数、当前待处理请求数输出到自定义状态文件。这样不需要打开日志就能知道是哪个站点在报错、哪个站点的产量正常。整个监控扩展大概几十行代码，但对排查问题省下大量时间。
6. 实测踩坑复盘：三条完整排查链路
6.1 少抓一类数据的排查全过程
项目上线后第一个异常表现为："tech站点的数据正常，politics站点的数据只有前一天有，后面全没了。"我首先怀疑的是Rule匹配问题，于是去看日志，结果politics站的抓取请求量确实有，量还不小，但Pipeline里落库的item数量明显少于请求数量。
排查链路走了一遍：先在parse_detail入口临时打了日志，确认字段都填上了；接着到DuplicateFilterPipeline检查，发现politics站点有大量重复URL被Redis判重拦截。原来这个站的栏目列表页会把同一篇文章同时挂在"推荐"和"最新"两个入口下，链接相同，但采集顺序跨了两条规则，一部分在抓取详情前就因重复请求被调度器直接忽略。
根因是：同一网站内不同站点的链接提取范围存在交叉，同一篇详情页被多条Rule或多次采集申请重复调度。我调整了restrict_xpaths，让每条规则的提取范围精确到对应栏目容器内，同时在去重Pipeline里对请求级去重和生产级去重做了区分，这才把问题解决。实践证明，LinkExtractor的restrict_xpaths不是可有可无的参数，多站点场景里它是防止重复请求的第一道闸门。
6.2 Rules顺序导致回调错配的根因
另一个让我困惑了半天的问题是：sports站点的详情页一直进不了parse_detail，反而被当作列表页递归抓取，产生了大量无意义的嵌套请求。
我一开始觉得Rules写得没问题：详情页规则在前，翻页规则在后。但实际看源码后发现，Rule匹配时并非"先匹配到就停止"，而是所有规则都会尝试匹配同一批链接，最终行为由响应处理的顺序和规则定义综合决定。当详情页URL同时匹配了详情规则和更宽泛的翻页规则时，Scrapy会把它分配给先定义且带callback的规则，但如果我的详情规则allow写得太严（比如要求URL里必须有某个数字格式），错误URL就会被宽松规则接走。
排查和修复的过程不算优雅：我把每个站点详情页URL的样本拉出来，逐一对着规则调试，最后把宽松翻页规则全部加上了restrict_xpaths，并且让详情规则尽量简洁准确。经验是：CrawlSpider多个Rules的顺序优先级并不像直觉那么好，写完之后一定要抓真实页面测一轮，确认每个站点都进了对应回调，再放开跑全量。
6.3 多Spider共享Pipeline时的隐性问题
最后一个值得说的坑：共享Pipeline中如果某个管道内部持有了状态，而多个spider同时使用这个管道实例，就可能出现状态串扰。
我的StoragePipeline一开始用了一个实例变量self.seen_count做统计，在多spider并行时发现统计数字互相覆盖，A站的数量被B站的请求冲掉了。排查后发现，Scrapy的Pipeline对每个spider会实例化一次，但不同spider的实例在同一个进程里共享同一个管道类的静态变量，如果我用的是类变量而不是实例变量，就会串。
修复很简单：把统计逻辑改成实例变量或干脆换成按spider的名字动态维护字典。但这个问题提醒了我一个原则：共享Pipeline里的任何状态都必须按spider维度隔离，不能假设同一时间只有一个spider在跑。同样适用于日志标签、告警频率控制这类隐性状态。
这套单工程多spider的架构用下来，最大感受是：当采集目标从"一两个网站"变成"十几个网站、每个网站还有一堆子站点"时，复杂度不会均匀地加在所有代码上，而是集中在规则编排和管道分流这两个地方。把筛选规则的粒度做细，把来源打标做扎实，把管道的状态隔离做好，整个系统就是稳定的。将来如果你要在这个基础上做全站更新检测或增量采集，只要在Pipeline前面再加一层指纹对比即可，骨架基本不用动。
