简介本资源是一款面向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 mysqlpymysql://user:passwordlocalhost: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/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.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, headersget_random_headers(), timeoutself.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_typelist): self.queue.append({url: url, parser_type: parser_type}) def run(self): with ThreadPoolExecutor(max_workersself.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(stripTrue) if title_tag else None, price: price_tag.get_text(stripTrue) 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, levellogging.INFO): logger logging.getLogger(name) logger.setLevel(level) handler RotatingFileHandler(log_file, maxBytes10 * 1024 * 1024, backupCount5) 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_typelist) 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 提交采集任务、查看进度框架的能力边界是由你的需求决定的模块化设计保证了你随时能在不伤筋动骨的前提下加新能力。我实际用下来的体会是这套框架最值钱的部分不是那几段能跑的代码而是“把采集工作拆成可维护模块”的思考方式。后续你再接触任何网站采集哪怕是完全不同的业务类型只要保持这条分层思路开发效率和维护体验都会有质的提升。最后再分享一个小技巧任何爬虫框架上线前先拿一个只有几百条数据的小分类试跑三天观察日志是否平稳、数据是否准确、是否有异常情况确认没问题再扩大到全量这个习惯能帮你避开绝大多数坑。本文还有配套的精品资源点击获取