基于Django与爬虫的二手房屋信息采集系统设计实现

看到这个题目，正在准备毕设的朋友应该能get到它的体量。名字虽然长，但拆开看其实非常典型——一套以 Django 为骨架、网络爬虫为数据来源、二手房屋二手房屋信息采集系统为核心的 Web 应用。这类题目在毕业设计里几乎年年都有类似版本，但真正做完并且能讲清楚的人并不多。因为它的难点不在于某个单一技术，而在于“数据采集 → 数据存储 → 数据展示 → 数据分析”这条链路能否完整打通。

这篇文章我就按自己实际做这个项目的思路，把整体设计、数据库建模、爬虫实现、后端接口、前端可视化以及论文和答辩准备全部讲一遍。内容适合正在做“Django+爬虫+可视化”方向毕设的同学，也适合想系统了解一个小型数据采集系统是怎么串起来的开发者。看完之后，你至少能独立复刻一个同类的完整系统，并能在答辩时把每个设计决策背后的理由说清楚。

1. 项目整体定位与技术选型：别把“大数据”想复杂

1.1 这个系统到底要解决什么问题

无论题目怎么写，二手房屋信息采集系统的核心业务就一句话：从目标房源网站采集公开的二手房挂牌数据，清洗后存入数据库，再通过 Web 端提供列表查询、条件筛选、数据统计和可视化展示。

注意这里有个容易让毕设跑偏的地方——题目里带着“大数据”三个字。很多同学一看到大数据就想着上 Hadoop、Spark，或者纠结数据量要到多少万条才算大数据。站在实际交付和答辩的角度，本科毕设里真正要展示的不是分布式算力，而是面向规模化数据的采集方法、清洗流程、结构建模和多维统计分析思路。哪怕最终落库的数据量是几千条到几万条，只要采集逻辑、去重策略、统计聚合、图表呈现这一整套链路是完整且合理的，就完全能撑起这个题目。你甚至可以理解成：大数据在这个场景里是一种“方法论”，而不是某种框架依赖。

系统解决的问题也很具体。对本科毕设而言，需要覆盖的核心功能至少包括：

• 用户注册登录，以及登录后的收藏功能
• 爬虫手动触发采集，展示采集进度和结果统计
• 房源信息的列表展示、多条件组合筛选、详情页
• 区域均价、价格趋势、户型分布等数据的可视化图表
• 数据导出，方便论文里放截图和数据佐证

把这些做好了，整个系统的业务闭环就完整了。其余花哨的所谓“智能推荐”“房价预测”如果不做深，答辩反而容易被追问到细节，风险更大。

1.2 技术栈选择：Django 为什么是毕业设计最优解

技术选型是论文里第一个会被问到的点，也是你所有代码的基础。我最终选择 Django 而不是 Flask，也不是 Spring Boot，核心原因有三个。

第一，Django 自带 Admin 后台。这个对毕设太友好了——爬虫采集完数据，你可以直接在后台看到所有房源记录，还能用 Django 自带的分页、过滤功能做临时排查。连增删改查的管理界面都省了，还能在论文里截图为“系统后台管理模块”。第二，Django 的 ORM 比直接写 SQL 更适合快速迭代和论文展示。你把模型类往 models.py 里一写，迁移命令一跑，表就建好了，而且字段类型、约束、索引在代码里一目了然，答辩老师看源码也方便。第三，Django 的模板系统配合 Bootstrap 和 ECharts，不需要单独做前后端分离，渲染效率高，也不会引入 Vue/Node 那一套额外的复杂度，对时间紧张的毕设来说是最稳妥的路线。

爬虫部分我用的是requests + BeautifulSoup4 + lxml，没有直接用 Scrapy。原因很现实：Scrapy 的工程化能力强，但它的流程是框架级的，调试样式和断点不够直观，本科阶段把 Scrapy 调通需要额外学习时间。而这个小项目的数据量、反爬压力、并发要求都不高，用requests发送请求、BeautifulSoup解析 HTML、ThreadPoolExecutor做适度并发，已经完全够用了。这不是说 Scrapy 不好，而是在毕设这个约束条件下，简单的方案更容易在出问题时被自己掌控。如果你在论文里想体现对爬虫框架的理解，可以画个对比，说明“本系统基于轻量级 requests 实现，兼顾可读性与可控性”，比硬上一套重框架更让人信服。

数据库我用的是 MySQL 8.0。虽然 SQLite 更方便，但论文写起来不好看，而且 MySQL 配套 Navicat 可视化查看数据非常直观，给老师演示的时候也专业一些。前端部分没有引入复杂的构建工具，就是 Bootstrap 5 + jQuery + ECharts 5，所有静态文件放在 Django 的 static 目录下统一管理。

1.3 模块划分：从架构图上就能看出业务层次

这个项目我建议在源码上就按功能拆成多个 Django app，而不是把所有逻辑堆在一个views.py里。我当时拆了三个业务 app：

• userapp：用户注册、登录、收藏相关
• houseapp：房源列表、详情、搜索筛选、统计图表、导出
• crawlerapp：爬虫触发、任务日志、采集统计

这样拆的好处是论文里的“系统设计”章节非常好写。你可以在系统架构图上把采集层、存储层、业务层、展示层四个层次画出来，每个层对应到具体模块。答辩时老师问“你的系统有哪些模块”，你从架构角度说会比从代码文件角度说清楚得多。

2. 数据库模型与项目结构设计：业务怎么落到表里

2.1 核心表结构设计

数据表是整个系统的地基。我建议设计五到六张表，既要保证业务完整，又不能冗余过度。下面是我整理的模型设计思路，用 Django 模型定义展示：

from django.db import models class HouseInfo(models.Model): # 房源基础信息 title = models.CharField(max_length=200, verbose_name="标题") community = models.CharField(max_length=100, verbose_name="小区名称") district = models.CharField(max_length=50, verbose_name="所在区域") address = models.CharField(max_length=200, verbose_name="地址") total_price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="总价（万元）") unit_price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="单价（元/平米）") area = models.DecimalField(max_digits=8, decimal_places=2, verbose_name="建筑面积（平米）") rooms = models.CharField(max_length=30, verbose_name="户型") orientation = models.CharField(max_length=20, verbose_name="朝向") decoration = models.CharField(max_length=20, verbose_name="装修情况") floor = models.CharField(max_length=50, verbose_name="楼层信息") listing_date = models.DateField(null=True, verbose_name="挂牌日期") longitude = models.DecimalField(max_digits=10, decimal_places=6, null=True, verbose_name="经度") latitude = models.DecimalField(max_digits=10, decimal_places=6, null=True, verbose_name="纬度") source_url = models.URLField(unique=True, verbose_name="来源链接") create_time = models.DateTimeField(auto_now_add=True, verbose_name="创建时间") update_time = models.DateTimeField(auto_now=True, verbose_name="更新时间") class Meta: db_table = "house_info" verbose_name = "房源信息" class CrawlTask(models.Model): # 爬虫任务记录，每次执行采集都往这里写一条 task_name = models.CharField(max_length=100, verbose_name="任务名称") status = models.CharField(max_length=20, default="running", verbose_name="状态") total_count = models.IntegerField(default=0, verbose_name="房源总数") success_count = models.IntegerField(default=0, verbose_name="成功数") fail_count = models.IntegerField(default=0, verbose_name="失败数") start_time = models.DateTimeField(auto_now_add=True, verbose_name="开始时间") end_time = models.DateTimeField(null=True, verbose_name="结束时间") class Favorite(models.Model): # 用户收藏表 user = models.ForeignKey("auth.User", on_delete=models.CASCADE, verbose_name="用户") house = models.ForeignKey(HouseInfo, on_delete=models.CASCADE, verbose_name="房源") create_time = models.DateTimeField(auto_now_add=True, verbose_name="收藏时间")

几个字段设计上容易被忽略的点，我单独说一下。

价格为什么统一存“万元”而不是“元”？因为散落在原始文本里的可能是“550万”“5.5万/平”“一室一厅总价200万”，只有统一口径才能在统计时做 AVG、SUM 聚合。总价和单价分开存也是同理，页面上的对比、排序、图表都能直接取字段，不用每次换算。

面积为什么用 Decimal 而不是 Float？因为 Float 在计算均值、排序时会遇到浮点精度问题，显示 89.99999 这种数据在论文截图里很尴尬。Decimal 能保证两位小数的精度稳定。

source_url设置唯一约束是去重的最后一道防线。爬虫代码里可能有各种解析漏洞，但只要来源链接不重复，入库时数据库层面就会把重复数据拦下来。配合 Django 的update_or_create，就能在重跑任务时做到增量更新而不是产生大量重复行。

2.2 项目目录结构组织

项目结构我建议这样组织，逻辑清晰且方便论文描述：

house_project/ ├── manage.py ├── requirements.txt ├── house/ │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── userapp/ │ ├── houseapp/ │ └── crawlerapp/ ├── templates/ │ ├── base.html │ ├── index.html │ ├── house_list.html │ ├── house_detail.html │ ├── stats.html │ └── login.html / register.html ├── static/ │ ├── css/ │ ├── js/ │ └── images/ └── docs/ ├── 需求分析.md └── 数据库设计说明.md

把requirements.txt放在项目根目录是个容易被忽略但很加分的好习惯。论文里写“系统运行环境”的时候，你直接贴这个文件的内容就行，评委老师想要复现也能一步到位。

2.3 数据库设计里的经验心得

我开发过程中踩过的一个小坑是给房源信息表加了太多字段，比如楼层总数、电梯、产权年限、挂牌时间等。字段越多，爬虫解析越容易出错，清洗规则越复杂，页面展示越散乱。毕设不是商业产品，建议先做减法：只要满足页面上能展示、统计图表能用、论文有内容可写，字段就够了。后面觉得不够再加，不要让第一版就背上沉重的字段包袱。

另一个建议是每个表都要有创建时间和更新时间。这两个字段不是摆设，区域均价走势图如果按挂牌日期聚合出现空白段，你可能需要排查是不是数据入库时间有问题。有了update_time，排查和调试都方便很多。

3. 爬虫采集模块实现：从页面解析到数据落库

3.1 先把目标页面结构拆明白

写爬虫之前一定要先人工打开目标房源平台的列表页，右键检查元素，把页面结构看清楚。以我当时调研的某房源平台为例，列表页的房源卡片通常都包在一个<div class="list-item">这样的容器里，卡片里面的字段分布模式大致是：

• 标题：<a class="title">的文本
• 小区名：标题文本中通常包含小区关键词，或者单独一个<div class="community">
• 总价：<span class="price">里的文本，类似“550万”
• 面积：<div class="area">里的文本，类似“89.5平米”
• 户型：类似“3室2厅1厨1卫”
• 楼层/朝向/装修：通常在同一个<div>里用/分隔

不要相信不同平台的页面结构完全一样，但要相信大多数房源平台的列表结构都符合“卡片 — 字段标签 — 字段值”这个套路。所以解析代码的核心思路就是用 compact 的选择器取出每个卡片对象，再在卡片内部继续查找子元素，而不是整页全局匹配。比如：

from bs4 import BeautifulSoup def parse_list_html(html_text): soup = BeautifulSoup(html_text, "lxml") items = [] cards = soup.select("div.list-item") for card in cards: title_tag = card.select_one("a.title") if not title_tag: continue item = { "title": title_tag.get_text(strip=True), "total_price_text": card.select_one("span.price").get_text(strip=True), "area_text": card.select_one("div.area").get_text(strip=True), "detail_url": title_tag.get("href"), } items.append(item) return items

这里有个细节容易踩坑：get_text(strip=True)能去掉文本首尾空格，但无法去掉文本内部的换行和多余空白。清洗阶段还需要再进一步处理，比如把“3室 2厅”中间的多个空格统一替换成半角。

3.2 请求策略与采集速率计算

请求层面最基础也最重要的就是请求头。目标站点通常会对非浏览器请求做校验，所以至少需要设置User-Agent和Referer。我一开始犯过的错误是只设置了 User-Agent，还是被拒绝，后来加上Referer之后才正常。这个细节论文里不值得展开写，但代码里必须体现。

采集速率方面，我提供一个可复用的估算方法。假设一个请求加解析需要 0.4 秒，采集 10000 条房源就需要 4000 秒，约 66 分钟。如果还要进入详情页抓更完整的数据，每多一个请求就多 0.3 秒左右，整体时间接近 2 小时。这个量级用 4 个线程并发就足够：

from concurrent.futures import ThreadPoolExecutor, as_completed with ThreadPoolExecutor(max_workers=4) as executor: future_map = {executor.submit(crawl_page, page_num): page_num for page_num in range(1, total_pages + 1)} for future in as_completed(future_map): page_num = future_map[future] try: result = future.result() save_page_data(result) except Exception as exc: logger.error(f"第{page_num}页采集失败: {exc}")

关于代理池，我的建议是毕设阶段不要碰。不是因为难，而是你一旦上了代理池，就要回答“代理失效怎么办”“代理质量怎么保证”这些延伸问题。更稳妥的做法是：本机出口 IP 直接采集，限制并发数，控制请求频率在每秒 1~2 个请求以内，把目标站点当成一个“尽量礼貌访问的公开数据源”。这样反而能表现出你对采集伦理的理解。

3.3 数据清洗与标准化入库

原始文本和库字段之间一定是有断层的。比如原始数据可能是这样：

价格：550万 面积：89.5平米 朝向：南 北 装修：精装 楼层：中楼层/共18层

入库之前要做标准化处理。我常用的方法是写一组小的解析函数，每个函数只干一件事：

import re def parse_total_price(text): # "550万" -> 550.00 match = re.search(r"([\d.]+)\s*万", text or "") return float(match.group(1)) if match else 0.00 def parse_unit_price(unit_price_text): # "61517元/平米" -> 61517 match = re.search(r"([\d.]+)", unit_price_text or "") return float(match.group(1)) if match else 0.00 def clean_space(text): return re.sub(r"\s+", "", text or "")

清洗规则看起来是一堆正则和字符串替换，但它是整个“大数据”流程里最体现工程能力的部分。论文里你可以把清洗规则整理成一个对照表：原始文本、清洗规则、标准化结果，这样一张表就是很好的论文素材。

入库的关键是update_or_create：

obj, created = HouseInfo.objects.update_or_create( source_url=item["source_url"], defaults={ "title": item["title"], "community": item["community"], "district": item["district"], "total_price": parse_total_price(item["total_price_text"]), # ... 其他字段 }, )

这个写法兼顾了首次采集和后续更新。第二次跑的时候，已经存在的房源只更新字段，不会新增重复行。唯一的代价是逐条写入会有点慢，但一万条数据用update_or_create实测大约几十秒，完全可以接受。如果后续数据量到了十万以上再考虑批量写，毕设阶段不用过度优化。

3.4 增量更新思路

增量更新听起来很高级，实际落地时可以很朴素。我用的是一个简单策略：每次跑任务前记录CrawlTask的开始时间，任务结束后统计这一轮新增了多少条、更新了多少条。重跑整个列表页时，因为使用了update_or_create，已存在的记录自动走更新，新发现的记录自动插入，天然就是“全量 + 增量”的混合行为。等到数据达到几十万条、全量重跑需要数小时的时候，再考虑按update_time只抓最近更新的数据。毕设阶段这个策略足够，答辩时也不会被问倒。

3.5 合规与采集边界：必须单独说清楚

写爬虫模块前我强烈建议你先明确自己的边界。毕业设计中使用爬虫，最重要的几条原则是：

• 只采集公开的商品挂牌信息，不采集任何个人敏感数据
• 遵守目标站点在访问规则中明示的限制，不做绕过行为
• 控制请求频率和并发，不使用恶意手段干扰站点正常服务
• 采集数据仅用于学习研究，不用于商业用途
• 代码中显式设置 User-Agent，并尊重目标站点的访问协议

这些不是空话。论文里单独列一条“数据采集合规说明”，答辩时老师会对你的工程素养有正面评价。相反，如果在代码里出现类似于“绕过验证码”“模拟登录破解”这样的实现，老师反而会追问你法律和道德层面的问题，得不偿失。

4. 后端业务与可视化展示：让数据真正“能用”

4.1 房源列表与组合搜索实现

房源列表是最核心的业务页面。它要支持按区域、价格区间、面积区间、户型等条件组合筛选，还要支持排序。Django ORM 里用条件判断拼查询集的方式来做：

def house_list(request): qs = HouseInfo.objects.all().order_by("-create_time") district = request.GET.get("district", "") min_price = request.GET.get("min_price", "") max_price = request.GET.get("max_price", "") min_area = request.GET.get("min_area", "") if district: qs = qs.filter(district=district) if min_price: qs = qs.filter(total_price__gte=min_price) if max_price: qs = qs.filter(total_price__lte=max_price) if min_area: qs = qs.filter(area__gte=min_area) # 分页 paginator = Paginator(qs, 12) page_number = request.GET.get("page") page_obj = paginator.get_page(page_number) return render(request, "house_list.html", {"page_obj": page_obj})

这里有个很隐蔽的坑：分页链接。如果模板里直接写?page=下一页，用户翻到第二页时筛选条件就丢了。解决办法是模板里把当前所有查询参数拼上，或者写一个简单的标签函数把request.GET的 QueryDict 复制一份，改掉page参数再输出到链接。这个小细节非常容易被忽略，但面试时实际演示筛选+翻页如果失效会非常尴尬。

4.2 统计图表的数据从哪里来

可视化部分我用 ECharts 画了三个核心图：区域均价柱状图、价格区间分布饼图、区域房源数量对比图。这些图的数据来源都是 ORM 聚合，不需要单独建统计表。

区域均价图的核心查询长这样：

from django.db.models import Avg, Count district_stats = ( HouseInfo.objects.values("district") .annotate(avg_unit_price=Avg("unit_price"), total_count=Count("id")) .order_by("-avg_unit_price") )

values("district")相当于 SQL 里的GROUP BY district，返回的每个字典里都有district、avg_unit_price、total_count三个键。前端渲染时我只要把这个列表序列化成 JSON 传给 ECharts 就行。用 Django 模板渲染 JSON 有几种方式，最容易出问题的是手动json.dumps后塞进模板变量，中文引号很容易被转义搞乱。我推荐用 Django 自带的json_script过滤器：

{{ district_stats|json_script:"district-stats" }}

然后在 JavaScript 里这样取：

const districtStats = JSON.parse(document.getElementById("district-stats").textContent);

这段代码能避免绝大多数引号转义问题，而且 HTML 结构也干净，便于后期排查。

还有一个容易踩的坑：聚合得到的avg_unit_price是 Decimal 类型，JSON 序列化时可能报错。遇到这个问题就在序列化前统一float()转一下。空值数据也是同理，聚合结果里平均值可能为None，要过滤掉或者补 0，不然图表会出现空白柱。

4.3 详情页、收藏与导出功能

详情页就是按主键查一条记录渲染详情模板，逻辑很简单。唯一要注意的是详情页的 URL 设计，我建议用/house/<int:house_id>/而不是查询参数?id=1的形式，对后面论文里写 RESTful 风格的接口描述更有利。

收藏功能我用的是单独一张收藏表。这里可以体现一个细节：收藏按钮的切换状态要在模板里判断当前用户是否收藏过当前房源。这个逻辑不复杂，但很能体现代码的完整性。

@login_required def favorite_house(request, house_id): house = get_object_or_404(HouseInfo, id=house_id) favorite, created = Favorite.objects.get_or_create(user=request.user, house=house) if not created: favorite.delete() return redirect("house_detail", house_id=house_id)

数据导出我做得比较朴素，直接导出 CSV。这里必须说一个坑：如果你用 Django 的HttpResponse输出 CSV，Excel 打开会中文乱码。解决办法是响应头里指定编码为utf-8-sig：

response = HttpResponse(content_type="text/csv; charset=utf-8-sig") response["Content-Disposition"] = 'attachment; filename="houses.csv"'

utf-8-sig会带 BOM 头，Excel 识别后中文就不乱码了。这个细节特别适合写进“系统测试与问题解决”章节，能体现你真刀真枪调试过。

4.4 前端页面组织：模板复用与页面交互

模板方面我建议做一个base.html，把导航栏、用户登录状态、CSS/JS 引入都放进去，子页面通过{% extends "base.html" %}继承。导航栏里放房源列表、统计分析、后台管理入口、登录/注册按钮。页面风格用 Bootstrap 默认风格，不要做复杂的自定义样式，干净整洁优先。

房源列表页的卡片建议用卡片式布局，每张卡片显示小区名、总价、面积、户型和区域。点击进入详情页，详情页里再展示完整信息。统计分析页放三个图表区域，上方放筛选条件（区域选择下拉框），下面图跟着联动。ECharts 的图表加载要在页面DOMContentLoaded之后初始化，这个新手特别容易踩坑——脚本放在head里执行时拿不到 DOM 节点，图表渲染不出来。统一把脚本放在body底部即可。

5. 调试记录、论文写作与答辩准备

5.1 常见问题速查与处理方案

我把这套系统开发和调试过程中遇到最多的问题整理成了一张表，基本上覆盖了这个项目 90% 的坑。

这每一个问题在开发和调试的时候都真实遇到过。论文里的“系统测试”章节就可以把这些问题整理成“测试中遇到的问题与解决方案”，比干巴巴写几个用例更有说服力。

5.2 说明文档与论文的写作顺序

很多学生习惯先写代码后写论文，结果写到“系统设计”时发现自己当初根本没留下设计过程。我的建议是论文写作顺序跟代码开发顺序保持一致，但写作时从文档视角重新梳理。

推荐的章节顺序是这样：

• 需求分析：重点描述系统解决什么问题，画出功能需求清单和用例图
• 技术选型分析：说明为什么选 Django + requests + MySQL，做一个横向对比表
• 数据库设计：直接放核心表结构，配合 ER 图（用常见绘图工具导出即可）
• 爬虫模块设计：放采集流程图、请求策略、数据清洗规则表
• 系统功能实现：按模块截图并解释核心代码逻辑
• 系统测试：功能测试用例表 + 上述问题排查表

论文的截图要尽早准备。系统做完后马上跑一遍完整流程，把首页、列表页、详情页、统计图表、后台管理、导出文件这些页面截图保存好。不要等到交了论文再临时截图，那时候代码可能已经被你改过几轮，页面风格和实现逻辑对不上，返工更麻烦。

5.3 答辩常问的问题与回答预判

答辩时评委大概率会从这几个角度提问，提前准备答案比临时发挥稳得多。

“为什么选 Django？”回答要点：开发效率高、自带 ORM 和 Admin、适合中小型 Web 系统的快速实现。这个回答不要只说“我们老师要求的”，要落到技术特性的客观分析上。

“你的数据一共多少条？怎么保证数据的准确性？”回答要点：数据量为几千条量级，准确性通过三方面保证：清洗规则校验（正则 + 类型转换）、数据库唯一约束去重、抽样人工核对。这几句话比空谈“可靠性”有说服力得多。

“如何处理反爬和频率限制？”回答要点：其一，遵守访问频率规范，限制并发；其二，设置合规的请求头；其三，只采集公开信息，不采用越权手段。按这个逻辑回答，不仅能体现技术能力，还能体现工程伦理，评委通常不会继续刁难。

“和市面上的房屋平台相比，你的系统有什么优势和不足？”回答要点：优势是面向学习研究、代码可控、可二次开发；不足是数据时效性不如商业平台、功能深度有限。承认不足反而体现真实的认知水平，比硬夸系统完美更稳妥。

最后分享两点实际体会

这套系统从零到完整交付，我前前后后调试了两周左右。最大的感受是：项目里最花时间的不是 Django 的那些增删改查，而是爬虫解析规则的维护。目标站点只要改一点 HTML 结构，你的选择器可能就全部失效。所以我后来养成了一个习惯——把所有列表页和详情页的解析规则单独放进一个配置文件里，站点改版时只改配置不动业务代码。虽然毕设阶段不需要这么讲究，但如果你想做得专业一点，这个设计在论文里是一个非常亮眼的“系统可维护性”论据。

第二个体会是，爬虫的清洗和解析函数一定要写成独立的小函数，并顺手写几个测试样例。比如parse_total_price("550万") == 550.0这种。哪怕手工跑一遍就行，也比你完整跑完一遍爬虫任务后再发现价格字段是字符串而报错要省时间得多。这个小习惯让我在后续改字段、调正则时省了大把精力。

如果你正准备做同类的毕设题目，按照“先设计业务模块 → 再设计数据库 → 然后实现爬虫清洗入库 → 最后做后端和图表展示”的顺序走，整个项目是可以稳稳拿下来的。过程中遇到任何解析、入库、渲染的问题，回到这张问题速查表里对号入座，基本就能解决大半。