Python爬虫框架设计：58同城全站信息采集源码解析

简介：本资源是一款面向Python爬虫学习者与数据采集工程师的58同城全站信息抓取框架源码，聚焦房产、招聘、二手车、二手交易等多类垂直领域，解决结构化数据批量获取难题，适用于市场分析、竞品调研及教学实践等场景。压缩包共26个文件（29KB），含13个.py源码文件（如spiders、pipelines、settings、middlewares等，构成Scrapy风格爬虫核心模块）、10个.pyc字节码文件（提升运行效率）、1个.cfg配置文件（支持环境参数定制）、1个.txt说明文档及1个.gitignore版本控制文件，目录结构体现典型爬虫工程分层设计。目前已有291人学习下载，读者可直接复用该框架的代理IP测试、User-Agent轮换、请求头模拟、HTML解析与数据管道处理等完整实现逻辑，并基于tc58、oncode_chao等模块快速适配不同城市与分类页面，显著降低反爬调试成本。 做爬虫的人都知道，真正难的不是写一个能跑的脚本，而是写一个能长期跑、改起来不头疼、遇到反爬不集体崩溃的框架。这个“基于Python的58同城全站爬取信息框架设计源码”项目，本质上就是把分散的爬虫逻辑收敛成一套可复用的工程骨架，让采集任务从“一次性脚本”升级成“可持续迭代的小系统”。这篇文章我会从设计思路、技术选型、核心模块实现到排查技巧完整拆一遍，适合正在从脚本式爬虫往框架式爬虫过渡的开发者参考，也适合准备做分类信息站点采集设计的同学收藏。

先说清楚一个重要前提：任何爬虫项目都必须严守合规底线。本文讨论的框架只采集公开信息、只用于个人学习研究，实际操作中请务必遵守目标站点的robots协议和服务条款，控制请求频率，不得影响网站正常运行，不采集涉及个人隐私的数据。有了这个前提，下面聊技术才有意义。

1. 项目定位与整体设计思路

1.1 为什么是框架而不是单个脚本

很多人入门爬虫的时候写过一个“经典三连”：requests 拿页面、正则抠数据、循环翻页。这种脚本用来抓几百条数据完全够用，但一旦数据量到了十万级、几十万级，或者目标站点的页面结构隔几个月就变一次，问题就全浮出来了。

脚本最大的问题是逻辑耦合。请求、解析、存储全挤在一个文件里，改一个解析规则可能牵连到请求逻辑，加一个字段要重新跑全流程，错了还得从头爬。更麻烦的是，一旦某个请求超时或者触发风控，整个脚本就卡死在那里，前面的数据全部白跑。所以框架化的第一个动机不是性能，而是解耦和维护。

这个58同城采集框架项目的核心目标可以拆成几条：

• 把抓取、解析、存储、调度拆成独立模块，互不干扰
• 支持配置化调整抓取频率、超时时间、重试次数，不靠改代码调参
• 所有模块可插拔，比如今天存 CSV，明天想存 MySQL，只改管道模块
• 采集过程有日志、有统计，挂了能知道挂在哪一步，而不是一头雾水

能做到这几点，哪怕目标换成其他分类信息网站，框架依然能用，只是换一套解析规则而已。

1.2 合规采集的边界怎么划

这个问题必须放在最前面聊。分类信息站点上有大量用户发布的公开信息，同时也有大量个人隐私，两者边界很模糊。我在设计这个框架时定了几条铁律：

• 只访问 robots 协议允许抓取的路径，明确禁止的路径不进队列
• 只采集业务需要的公开字段（如标题、价格、区域、发布时间），联系方式等涉及个人隐私的内容一律不采集
• 设置了单 IP 请求频率上限（下面会讲具体参数），宁可慢，绝不触发对方安全策略
• 采集数据仅用于个人技术学习和研究，不对外提供查询服务，不用于任何商业用途

这套边界不是道德绑架，而是实实在在保护自己。把规范围进来，反而能让你更专注于框架本身的设计质量。

1.3 框架的总体架构设计

这个项目采用的架构和 Scrapy 的思路接近，但做了精简和定制，方便二次开发和调试。核心分成六个模块：

• 配置层：全局参数，包括请求频率、超时、并发数、存储方式
• 调度器：管理任务队列，决定先抓哪些 URL、按什么顺序抓
• 下载器：负责发请求、拿响应，处理重试、异常、频率控制
• 解析器：把 HTML 变成结构化字段，不同页面类型对应不同解析器
• 管道：处理数据清洗、去重、存储，是数据出口
• 日志与监控：记录请求成功/失败情况，输出运行状态指标

模块之间只通过“任务”和“数据条目”这两个对象通信，不直接互相调用方法。这样的好处是每个模块都能单独测试，单独替换。比如下载器今天用 requests，明天想换成 httpx 异步版，只要保持接口不变，其他模块完全不用动。

2. 技术栈选型与组件拆解

2.1 请求库：requests 还是 httpx 还是 Scrapy

这个框架最开始我用的是 requests，理由很简单：生态成熟、资料多、几乎零学习成本。requests 的 Session 对象可以复用连接池，对于高频请求场景性能比裸 http 好很多。后来引入了 httpx 作为备选，因为 httpx 同时支持同步和异步，如果哪天真要做高并发了，切换成本比 requests 低。

Scrapy 我也认真评估过。Scrapy 功能确实强，内置了去重、调度、中间件、扩展，性能也高，但有两个问题：一是学习曲线陡，对新手不友好；二是很多功能当前项目根本用不上，属于“杀鸡用牛刀”。而且 Scrapy 的调试体验相对重，出了问题要翻一堆日志，反而拖慢开发速度。所以最终框架的下载器是自己写的轻量版，只保留真正需要的几个能力：超时控制、重试机制、随机请求头、频率控制器。

2.2 解析器：BeautifulSoup 与 lxml 怎么选

页面解析我用的是 BeautifulSoup + lxml 解析器的组合。BeautifulSoup 的 API 非常友好，定位节点、查找属性、遍历子元素都直观，写起来效率高，对新手尤其友好。lxml 作为底层解析引擎，解析速度比纯 Python 的 html.parser 快好几倍，两个加一起兼顾了开发效率和运行性能。

这里有一个很多人忽略的细节：BeautifulSoup 的soup.select()走的是 CSS 选择器，soup.find_all()走的是方法链，两者混用很容易造成代码风格混乱。我的做法是统一用 CSS 选择器，把每个字段的选择器集中在解析器文件顶部的字典里，后续页面改版只需要改字典对应的值，不需要去翻解析逻辑。

正则表达式在解析器里只做一件事：提取页面里嵌在 JavaScript 变量中的 JSON 数据。分类信息站点有些关键字段是渲染在<script>标签里的，JSON 格式，用正则把整段截出来之后 json.loads 解析，比 DOM 定位稳定得多。但正则只作为补充手段，绝不用来解析整个 HTML。

2.3 数据存储设计：CSV、MySQL 还是 MongoDB

数据存储这个模块我做了三套实现，通过配置项切换，方便不同场景使用。

• CSV：适合快速验证、数据量小、临时分析。优点是可视化强，Excel 直接打开看，缺点是不支持并发写入、没有去重约束
• MySQL：适合正式环境。设计表结构时把 URL 设为唯一索引，从数据库层面支持去重，同时支持增量更新
• MongoDB：适合字段结构经常变的场景。今天多一个字段、明天少一个字段，文档型数据库不用改表结构

对于这个项目，主要推荐 MySQL 方案。分类信息数据有明确的实体属性（标题、价格、区域、发布时间），关系型存储更规范。唯一索引去重很关键，因为请求可能重复，解析可能重复，落库前的最后一道关卡必须由数据库兜底。

2.4 任务调度与分布式扩展方案

单机跑这个框架能扛住绝大多数个人项目的数据量，但为了后续扩展，我在设计时预留了分布式接口。核心思路是去掉本地队列，换成 Redis 列表类型的左进右出操作，多个 worker 实例从同一个队列里取任务，天然支持分布式。

做法很简单：调度器的add_task方法从往本地 deque 里 append 变成往 Redis 里lpush，下载器的get_task从 deque 的 popleft 变成 Redis 的brpop。整个改动只涉及调度器和下载器两个模块，其他模块完全不受影响。如果你后续要接 Celery、RQ 这类任务队列，也是一样的思路，只不过替换掉队列实现而已。

3. 框架核心模块设计与实现

3.1 配置管理层：一份配置管遍所有环境

配置模块是整个框架的动作指挥中心。我把配置全部放在config.py文件里，用 Python 类加类属性的方式组织，而不是用复杂的 YAML 加载器，主要是图省事。Python 文件本身就是配置，写注释方便，改完不用重启直接生效，调试的时候特别顺手。

class Config: # 请求相关 BASE_URL = "https://example.com" DEFAULT_TIMEOUT = 10 # 单次请求超时，单位秒 MAX_RETRY = 3 # 单 URL 最大重试次数 REQUEST_INTERVAL = (1.5, 3.5) # 请求间隔范围，随机取值 MAX_CONCURRENT = 5 # 并发线程数 # 存储相关 STORAGE_BACKEND = "mysql" # csv / mysql / mongodb MYSQL_DSN = "mysql+pymysql://user:password@localhost:3306/spider_db" # 日志 LOG_LEVEL = "INFO" LOG_FILE = "logs/spider.log"

为什么请求间隔用一个范围而不是固定值？因为固定间隔会被轻易识别出机器行为特征，而随机间隔更接近人的操作习惯。这个细节后面会详细讲参数怎么算的。

3.2 请求头与身份信息管理

请求头是爬虫与目标站点识别博弈的第一道防线。我把请求头管理单独拆成utils/headers.py，内置一个 UA 池，每次请求随机挑一个。

import random UA_POOL = [ "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15", "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36", ] def get_random_headers(): return { "User-Agent": random.choice(UA_POOL), "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", "Connection": "keep-alive", }

UA 池只放了常见浏览器的真实 UA，没有放爬虫框架的默认 UA，这样最稳妥。另外提醒一句：不要盲目伪造 Referer，如果目标站点的资源路径有防盗链，Referer 造错反而更容易触发风控。这个项目不涉及图片等资源下载，所以 Referer 不刻意设置。

Cookie 处理上，框架支持两种模式：无 Cookie 模式和有 Cookie 模式。无 Cookie 模式适合采集完全公开的信息；如果后续遇到需要登录后才可见的信息，可以把 Cookie 字符串配到 config 里，下载器自动塞进请求头。但是注意，这里只是透明处理 Cookie，不是用来突破权限限制的，能看的数据才看，不能看的就不碰。

3.3 下载器核心实现：重试、超时与频率控制

下载器是整个框架的“手”，负责真正把数据拿回来。我实现的下载器核心逻辑是：带上随机请求头发请求，处理各种异常，遇到 403/429 就认为触发风控，自动拉长等待时间后重试，超过最大重试次数就放弃并记日志。

import time import requests from utils.headers import get_random_headers class Downloader: def __init__(self, config): self.session = requests.Session() self.timeout = config.DEFAULT_TIMEOUT self.max_retry = config.MAX_RETRY self.interval = config.REQUEST_INTERVAL self.last_request_time = 0.0 def _throttle(self): """请求频率控制：确保距上次请求至少间隔指定时间""" elapsed = time.time() - self.last_request_time min_interval = random.uniform(*self.interval) if elapsed < min_interval: time.sleep(min_interval - elapsed) self.last_request_time = time.time() def fetch(self, url): self._throttle() for attempt in range(self.max_retry): try: resp = self.session.get(url, headers=get_random_headers(), timeout=self.timeout) if resp.status_code == 200: # 部分站点乱码时需要按实际编码重新解码 resp.encoding = resp.apparent_encoding or resp.encoding return resp.text if resp.status_code in (403, 429): wait_time = 10 * (attempt + 1) time.sleep(wait_time) continue return None except requests.RequestException as e: time.sleep(2 * (attempt + 1)) return None

代码里有几个点值得讲：

• _throttle()是频率控制的灵魂函数。每次请求前检查距上次请求的间隔，如果小于设定的随机下限就休眠补足。这个控制放在下载器内，意味着无论调度器怎么并发调度，最终发出去的请求频率都被限制住，不会瞬间打爆对方服务器
• resp.apparent_encoding是 requests 根据网页内容自动推断的编码，能解决相当一部分乱码问题。但这个方法在部分场景下会误判，所以后面解析模块还会再做一层编码兜底
• 403 和 429 处理是重点。429 是限流，403 可能是 UA 被识别，也可能确实是权限不足。无论哪种，直接拉长等待重试是成本最低的应对方式，而不是临时改 UA。如果连续多次触发，就应该停下来人工检查，而不是让程序无限循环

3.4 调度器：任务队列与并发控制

调度器负责把待采集 URL 排好队，按一定规则分发给下载器。单机版我用collections.deque加线程池实现，简单可靠。

from collections import deque from concurrent.futures import ThreadPoolExecutor, as_completed class Scheduler: def __init__(self, config, downloader, parser, pipeline): self.queue = deque() self.config = config self.downloader = downloader self.parser = parser self.pipeline = pipeline self.stats = {"success": 0, "failed": 0} def add_task(self, url, parser_type="list"): self.queue.append({"url": url, "parser_type": parser_type}) def run(self): with ThreadPoolExecutor(max_workers=self.config.MAX_CONCURRENT) as executor: all_tasks = [] while self.queue: task = self.queue.popleft() future = executor.submit(self._process_task, task) all_tasks.append(future) for future in as_completed(all_tasks): future.result() def _process_task(self, task): html = self.downloader.fetch(task["url"]) if html is None: self.stats["failed"] += 1 return items = self.parser.parse(html, task["parser_type"]) for item in items: self.pipeline.process(item) self.stats["success"] += 1

线程池的问题在于无法动态调整并发数，运行时想改只能重启。但这个项目的数据量级下完全够用。如果你要做几十万页的大规模抓取，建议把队列换成 Redis 加多个进程，或者干脆上 Celery，框架的模块边界已经留好了，换起来不伤筋动骨。

3.5 解析器抽象：不同类型页面互不干扰

58同城这种分类信息站点，列表页和详情页结构完全不同，所以解析器做了一个基类加多个子类的设计。基类规定好parse方法的输入输出格式，子类各自实现具体的解析逻辑。

from bs4 import BeautifulSoup class BaseParser: def __init__(self): self.fields = {} def parse(self, html, parser_type): raise NotImplementedError class ListParser(BaseParser): """列表页解析器：提取每条信息的标题、价格、链接、区域""" def __init__(self): super().__init__() self.selectors = { "title": "h3", "price": ".price", "area": ".area", "link": "a.title", } def parse(self, html, parser_type): soup = BeautifulSoup(html, "lxml") results = [] for item in soup.select(".list-item"): title_tag = item.select_one(self.selectors["title"]) price_tag = item.select_one(self.selectors["price"]) link_tag = item.select_one(self.selectors["link"]) results.append({ "title": title_tag.get_text(strip=True) if title_tag else None, "price": price_tag.get_text(strip=True) if price_tag else None, "url": link_tag["href"] if link_tag and link_tag.has_attr("href") else None, }) return results

解析器里的选择器设计有一个原则：尽量选稳定的容器类名，不要选那种后端工程师随手改的 id 或者内联样式类名。通过实际对比，.list-item这种语义化类名比.fl这种纯样式类名稳定得多。另外所有字段都做了空值兜底，元素不存在时返回 None 而不是抛异常，这就是框架稳定性的一部分。

3.6 数据管道与去重机制

管道模块是所有数据的出口，也是框架里最应该“厚”的一个模块。我做的管道做了三件事：清洗、去重、存储。清洗包括去掉字符串首尾空白、格式化价格字段、处理时间格式；去重通过一个内存集合和数据库唯一索引双重保证。

class Pipeline: def __init__(self, config): self.storage = self._init_storage(config) self.seen = set() def process(self, item): cleaned_item = self._clean(item) if not cleaned_item["url"]: return False key = cleaned_item["url"] if key in self.seen: return False self.seen.add(key) self.storage.save(cleaned_item) return True def _clean(self, item): result = {} for k, v in item.items(): if isinstance(v, str): v = v.strip() result[k] = v return result

去重为什么要双保险？内存集合在运行过程中能快速过滤，但进程一重启就没了。数据库唯一索引是持久化的最后防线，即使程序崩溃重启，重复数据也进不了库。seen集合可能会随运行时间增长占内存，但本项目数据量级可接受，真到几百万条再考虑换 Redis Set。

3.7 日志与运行状态监控

爬虫跑起来最怕的是什么？不是报错，而是“看起来在跑其实一个数据都没抓到”。没有日志的爬虫就像一个不说话的定时炸弹。所以日志模块从第一天就做进去了，采用 Python 标准库 logging 加 RotatingFileHandler，按文件大小轮转，防止日志文件无限膨胀。

import logging from logging.handlers import RotatingFileHandler def setup_logger(name, log_file, level=logging.INFO): logger = logging.getLogger(name) logger.setLevel(level) handler = RotatingFileHandler(log_file, maxBytes=10 * 1024 * 1024, backupCount=5) formatter = logging.Formatter("%(asctime)s [%(levelname)s] %(name)s: %(message)s") handler.setFormatter(formatter) logger.addHandler(handler) return logger

日志不仅记录错误，还记录每个关键环节的进度。我会在解析器解析完每个列表页后打印本条记录数，在管道存储完一条数据后打印当前累计入库数。有了这些基础信息，才能知道任务跑到什么程度了、哪类页面解析率为零、哪个环节耗时最长。

4. 实操过程：从0到1搭建框架

4.1 环境准备与项目结构骨架

建议用一个干净的 Python 3.10+ 虚拟环境。依赖只有四个：requests、beautifulsoup4、lxml、pymysql，如果需要 MongoDB 再装 pymongo。项目骨架我习惯这样组织：

spider_framework/ ├── config.py # 全局配置 ├── run.py # 程序入口 ├── core/ │ ├── __init__.py │ ├── downloader.py # 下载器 │ ├── scheduler.py # 调度器 │ ├── pipeline.py # 数据管道 │ └── parser.py # 解析器基类 ├── spiders/ │ ├── __init__.py │ ├── list_parser.py # 列表页解析 │ └── detail_parser.py # 详情页解析 ├── utils/ │ ├── __init__.py │ ├── headers.py # 请求头管理 │ └── logger.py # 日志 ├── logs/ └── requirements.txt

这个结构把“框架”和“具体站点逻辑”分开了。core目录下的类完全不知道自己在爬哪个网站，只负责通用流程；spiders目录才是跟58同城强相关的东西。哪天要换站采集，只需要在spiders里加一套解析器，core一行不用动。

4.2 核心模块接线与运行入口

各模块在run.py里完成装配。装配过程写得极其直白，没有任何黑魔法，方便你调试的时候断点进去看。

from config import Config from core.downloader import Downloader from core.scheduler import Scheduler from core.pipeline import Pipeline from spiders.list_parser import ListParser from utils.logger import setup_logger def main(): config = Config() logger = setup_logger("spider", config.LOG_FILE, config.LOG_LEVEL) downloader = Downloader(config) parser = ListParser() pipeline = Pipeline(config) scheduler = Scheduler(config, downloader, parser, pipeline) # 手动构造初始任务：列表页第1页到第5页 for page in range(1, 6): url = f"{config.BASE_URL}/ershoufang/pg{page}/" scheduler.add_task(url, parser_type="list") logger.info("任务启动，初始任务数量: %s", len(scheduler.queue)) scheduler.run() logger.info("任务结束，成功: %s, 失败: %s", scheduler.stats["success"], scheduler.stats["failed"]) if __name__ == "__main__": main()

从第1页到第3页先小规模跑通，验证数据正确后再扩大到全量。这里的分页 URL 规则是从实际页面里总结出来的，不同分类的 URL 规则可能不一样，需要先人工打开几页确认规律，别想当然，这是我踩过不少次的坑。

4.3 参数计算与频率控制阈值设定

频率控制参数是整个框架里最需要“算”的地方。我实测下来，对于一个普通中小型网站，单 IP 每秒 1-2 个请求是比较安全的范围，但这只是起步值，具体要结合目标站点的规模来定。

拿每页约 60 条数据来算：如果设定请求间隔为 1.5 到 3.5 秒随机，取平均值 2.5 秒，一分钟大约发 24 个请求，一小时约 1440 个请求。抓 10 万条数据，平均每条信息所在页可能还要再抓详情页，假设共需 2000 个列表页加 5000 个详情页，总计 7000 个请求，约 4.9 小时跑完。这个速度对个人项目完全够用，也基本不会对目标站造成压力。

为什么不把并发线程数调更高？因为我做过对照实验：并发数从 5 调到 10，总耗时几乎没下降，因为瓶颈是频率控制，不是下载速度。并发数调高只会让更多线程卡在time.sleep()里等着，还增加了被风控的概率。真正想提速，正确的方向是换更大的 IP 池或者用分布式多机，而不是无脑堆线程。

4.4 运行效果验证与数据质量检查

跑完一轮之后，不要急着看数据量，先做三件事：

• 随机抽样 20 条数据，人工对比网页原页面，确认字段解析准确率
• 查数据库重复率，确认去重逻辑生效
• 看日志里 403/429 出现的次数，如果超过总量的 5%，说明频率太快，下次调大间隔

这个环节最容易翻车的是“某些字段全为空”。比如列表页里的区域信息，可能是懒加载渲染的，初始 HTML 里根本没有，解析器当然提取不到。这时候先检查响应文本里到底有没有目标字段，没有的话就得考虑用渲染工具或者改从详情页取字段。工具选型上不要一开始就上无头浏览器，先想清楚是不是真的需要渲染，因为无头浏览器的性能和稳定性都远不如纯 HTTP 请求。

5. 常见问题与排查技巧实录

5.1 遇到验证码或风控怎么办

这是最容易被问到的，也是必须谨慎处理的问题。我的框架碰到的处理方式是“三段式”：

• 第一层：降低频率。先检查间隔是否太短、并发是否太高，调成保守值再观察
• 第二层：轮换策略。换一组更贴近真实浏览器的 UA，清理可能被污染的 Cookie，但绝不模拟绕过验证码的机制
• 第三层：主动暂停。一旦检测到连续大量验证码或 403，程序自动停止并发送告警日志，等人工介入确认原因后再重新启动

这里有个心态问题需要说清楚：出现验证码不等于“失败了”，而是你的程序撞到了边界。强行突破的代价远超那点数据，完全可以调整采集范围或降低频率。合规采集的前提下，有些页面拿不到就放弃，不影响整个框架的可用性。

5.2 页面结构改版导致解析失败怎么定位

分类信息站点改版比较频繁，最常见的问题是解析器报AttributeError或者返回的字段全是 None。排查思路分三步：

• 先看日志里最近一次成功的 URL 是什么，把那个 URL 重新放到浏览器里打开，比对新旧页面结构
• 打开浏览器开发者工具，检查对应字段的 HTML 结构是不是变了，类名是不是换了
• 修改解析器里的选择器字典，保存后重跑单条 URL 验证

为了快速定位解析失败，我建议在解析器里给每个字段打一条 DEBUG 日志，打印定位到的元素数量。如果选择器一个元素都没匹配到，问题大概率就是改版了，而不是数据为空。

5.3 乱码问题的两种解法

中文网站乱码几乎每天都会遇到。第一种解法是在响应层面解决，用resp.encoding = resp.apparent_encoding先处理一遍，前面下载器代码里已经写了。第二种是在解析层面兜底，如果发现 HTML 里已经是乱码，可以在解析器里强制指定编码再交给 BeautifulSoup，例如html.encode("latin1").decode("utf-8")这种经典的“双重反转”技巧。

不过说实话，requests 的apparent_encoding大部分情况下都够用，只有在极少数编码声明错误的页面才需要第二种。写完框架跑一个月，我统计过乱码问题只占所有采集异常的 3% 左右，相比解析失败的比例低很多。

5.4 数据去重与断点续跑

爬虫不崩溃是不可能的，关键是崩溃之后怎么办。我的框架做了两层保护：

• 爬虫启动时从数据库里读出已有的 URL 集合，初始化seen集合，实现断点续跑
• 管道存储使用 INSERT IGNORE 语句（MySQL），唯一索引冲突时直接跳过，不影响主流程

第一版框架没做断点续跑，结果跑到一半程序挂了，重启后所有数据重新抓一遍，不仅浪费资源还产生了大量重复数据。后来加上这个逻辑，重启只需要十几秒就能恢复到停止点，体验完全不一样。

5.5 性能瓶颈分析与后续扩展

单机模式跑了一段时间后，如果数据量上涨，要关注的性能瓶颈有三个：请求等待时间、解析 CPU 时间、数据库写入吞吐。请求等待是最大的瓶颈，因为频率控制决定了它快不了；解析用 lxml 已经很快了，不是瓶颈；数据库写入可以用批量提交优化，比如攒够 100 条再 commit，能减少事务开销。

后续扩展方向我给你几个具体的：

• 把本地队列换成 Redis，实现多 worker 分布式采集
• 在管道模块接入 RabbitMQ 或 Kafka，把采集和数据消费彻底解耦
• 页面解析改成配置驱动，把选择器放到数据库或配置中心，改版时不用发版
• 加一个简单的 Web 管理面板，通过 API 提交采集任务、查看进度

框架的能力边界是由你的需求决定的，模块化设计保证了你随时能在不伤筋动骨的前提下加新能力。我实际用下来的体会是，这套框架最值钱的部分不是那几段能跑的代码，而是“把采集工作拆成可维护模块”的思考方式。后续你再接触任何网站采集，哪怕是完全不同的业务类型，只要保持这条分层思路，开发效率和维护体验都会有质的提升。最后再分享一个小技巧：任何爬虫框架上线前，先拿一个只有几百条数据的小分类试跑三天，观察日志是否平稳、数据是否准确、是否有异常情况，确认没问题再扩大到全量，这个习惯能帮你避开绝大多数坑。

本文还有配套的精品资源，点击获取