毕业设计选“全国二手房数据分析系统”这个题目的学生，这几年我见过非常多，但真正做明白的人真不多。原因很简单：这个题目看起来简单，实际要跨三个完全不同的技术栈——爬虫采集、Web后端、可视化前端，中间还夹着数据清洗和建模。任何一个环节卡住，整个系统就转不起来。也正因为它“链条长、环节多”，所以毕业设计答辩时特别好讲，只要你真把每个环节跑通了，评委老师很难问倒你。这也就是为什么我说这个题值得收藏、值得照着做一遍——它几乎是把数据分析类毕设的完整套路浓缩在了一个项目里。
下面我直接按我实际操作过的方式，把这个系统从爬虫到可视化的完整拆解写出来。代码层面的核心思路会给到，但更重要的是那些文档里不写、只有踩过坑才知道的细节。尤其在学校借来的服务器上、在实验室的共享网络里，你会遇到哪些奇奇怪怪的问题，我都会讲。
1. 选题与技术栈：为什么二手房数据是毕业设计的“万能题材”
1.1 这个题目到底考什么
先看题目关键词：全国二手房数据分析系统、Django框架、Requests爬虫、可视化、房屋/房源。
很多人拿到题目以后就开始焦虑，觉得“全国”两个字太大了，是不是要把全国每个城市的房源全爬下来？不是的。我理解“全国”在这里是一个数据范围描述，实际你只需要抓取你选定的几个重点城市（比如北上广深杭），或者在链家、贝壳这类公开平台的城市列表里选取若干城市即可。毕业设计的核心考核点是你有没有完整跑通一条数据链路，而不是你的数据量有多大。
这条链路就是：
- 用Requests从目标网站抓取房源列表页和详情页数据；
- 把抓到的原始数据解析成结构化记录（小区名、面积、户型、朝向、单价、总价、区域、所在楼层等）；
- 存入数据库；
- 用Django把数据以API或页面形式提供给前端；
- 前端用ECharts等可视化库把统计数据变成图表；
- 基于图表产出分析结论，体现“数据分析”而不是“数据展示”。
所以，这个题目本质上是一次全栈小项目训练，爬虫只是其中一个环节，Django后端和数据建模才是重头戏。
1.2 技术栈选型的理由和替代方案
先说Django。它几乎是国内高校毕业设计使用率最高的Python Web框架，原因很务实：
- 自带ORM，不需要手写SQL，答辩时说“我用了Django ORM做数据库操作”是很标准的加分话术；
- 自带Admin后台，数据入库后可以直接在后台检查、修改、删除，省去大量调试时间；
- 自带CSRF防护、用户认证体系，论文里讲到“安全性设计”时有东西可写；
- 生态成熟，资料多，网上随便一搜就是“Django项目实战新手教程”，卡住了不容易陷入孤立无援的境地。
相比Flask，Flask更轻量，但很多功能要自己装第三方库，答辩时你还要解释Flask-SQLAlchemy、Flask-Restful这些额外的依赖，增加了工作量。相比Spring Boot，Java系的Web框架在“专业度”上确实更高，但Python在整个数据采集和分析链路上的优势无可替代——Requests、Pandas、ECharts的配合太顺畅了。如果你是计算机专业、论文方向是数据分析，Django就是性价比最优解。
再说Requests。有人会问，现在爬虫是不是都用Scrapy？为什么不用Scrapy？我做毕设的建议是：如果时间充裕、想写得华丽一点，Scrapy可以加分；如果时间紧、想把精力放在数据分析和可视化上，Requests绝对够用，而且更好讲清楚原理。
Requests抓取页面的逻辑非常直白：模拟浏览器发HTTP请求，拿到HTML，然后用解析库提取数据。你只需要关心请求头、参数、响应内容这三件事，不需要理解Scrapy的引擎、下载器中间件、Spider中间件那一整套异步框架。对毕业设计而言，简单可靠、能稳定讲解原理，比架构酷炫重要得多。
可视化方面，主流选择是ECharts。理由只有一个：它最容易出效果，百度可视化大屏风格的案例模板遍地都是，改改数据源就能用。校内的答辩评委看得最多的就是大屏和图表，ECharts做出来的视觉效果够用、够好看。
2. 爬虫层：Requests把房源数据抓下来
这一部分我按“先分析目标网站，再写代码，再处理反爬”的顺序来讲，这也是我建议你自己动手时的顺序。不要一上来就写爬虫代码，你会乱。
2.1 抓什么、怎么抓：信息架构分析
打开任何一个二手房房源平台，你会发现列表页和详情页的信息分工很明确：
- 列表页：展示房源标题、小区名称、位置、户型、面积、朝向、总价、单价，以及分页链接；
- 详情页：包含更详细的信息，比如房屋年限、产权、建筑年代、所在楼层、装修情况、供暖方式、挂牌时间，甚至带看记录。
做数据分析时，列表页的信息基本够用，详情页的信息能丰富分析维度（比如“房龄对价格的影响”）。但详情页请求量比列表页大一个数量级，反爬风险也更高。我的做法是：列表页为主，详情页选择性抓取。抓取字段包括小区名称、所在区域、街道、户型、面积、朝向、楼层、总价、单价。这九个字段足以支撑大部分分析维度。
在技术实现上，需要先搞清楚目标网站的URL规律。比如某些平台的城市首页URL是https://xxx.com/{city}/，列表页是https://xxx.com/{city}/ershoufang/pg{n}/，其中{}是城市拼音，{}是页码。你要做的就是用浏览器打开开发者工具，在“网络”面板里看实际请求的URL、请求头、Query参数，把规律找出来。
这里我特别提醒一句：你必须确认目标平台是否允许爬虫访问，以及它的robots协议是怎么写的。毕业设计是为了学习演示，正确的做法是控制频率、只抓必要数据、不抓个人隐私信息、不用于商业用途。如果平台公开接口可以直接用，优先用公开接口；如果只能抓页面，也要保持克制。实际写代码时，尽量在模拟的测试环境中调试，别对线上平台形成压力。
2.2 请求头、频率和反爬：被429打爆之后的修复经验
访问频率控制是爬虫新手最容易忽视、也是被反爬打击最狠的环节。几乎每个人都会遇到：一开始爬得很快，几十个请求之后，返回码突然变成429 Too Many Requests，然后被网站限制访问。这也是相关热词里为什么会有“exceeded retry limit, last status: 429 too many requests”的原因。
429的意思是你的请求太频繁了，触发了网站的限流。处理办法有几种：
第一，降低频率，在每次请求之间加延时。最基础的做法是time.sleep(random.uniform(1, 3))，在1到3秒之间随机睡眠。为什么随机？因为固定间隔反而容易被识别出是程序。这个最简单，也是最重要的一步。
第二，设置合理的请求头。至少要带上User-Agent、Referer、Accept-Language。User-Agent不要用默认的Python-requests标识，换成浏览器的UA。我当时用的是Chrome的UA加一个常见的移动端UA做切换——有些平台对移动端UA限制更少。
第三，维护一个代理池。这是进阶做法，毕设阶段可选。如果只是在校园网里爬，同一个IP出口，无论怎么换UA都逃不过限流，可以考虑把钱放在“策略”上而不是“代理”上：把要抓的城市分散开、抓取时间段拉长、每次少量抓取，分几天完成。这样既不会触发限流，也不需要花钱买代理。我在实际操作中就体验过一天抓两三百条数据，连续抓三五天，期间一次429也没遇到；反而是想一口气抓完的时候，马上被限制。
第四，处理429响应本身。你不能假设永远不触发429，代码里要有重试机制。响应的状态码不是200时，等待一段时间后重试。我常用的是指数退避重试：第一次等待5秒，第二次15秒，第三次45秒，超过一定次数就放弃。
核心原则：爬虫不是越快越好，而是稳。能稳定把数据抓下来，永远不会被反爬“打死”，就已经超过很多只会写单页爬虫的同学了。
2.3 数据解析的几种写法和取舍
拿到HTML响应之后，解析数据主要有两条路线：正则表达式和XPath。热词里提到了“python xpath爬虫 text函数”，这值得展开。
正则的优点是不需要额外解析库，但它基于文本模式的匹配，网站页面一旦改版，正则几乎必然失效，而且它不擅长处理嵌套很深的HTML结构。我建议用XPath，配合lxml库。XPath的好处是你可以基于HTML的树状结构做定位，比如“提取所有标签里，属性包含‘data-house-code’的节点”，一下子就能匹配出来。写代码的方式大致是：
from lxml import html doc = html.fromstring(page_source) # text函数用于提取节点下的纯文本 titles = doc.xpath('//div[@class="title"]/a/text()') prices = doc.xpath('//div[@class="totalPrice"]/span/text()')text()函数在XPath里用来获取节点的文本内容，类似Scrapy里::text的作用。需要注意的一点是，如果目标节点的文本被拆散在多个子节点里，直接text()可能取不全，这时可以改用string(.)来获取节点下所有子文本的拼接结果。
这里我踩过的坑是：某些房源数据是页面里的JavaScript动态渲染出来的，直接访问HTML里根本没有。试过单纯用Requests抓下来发现是空壳页面，列表中所有房源字段都不在HTML里。正确的应对方式有两个：
- 在开发者工具里找到真实的数据请求接口，这种接口大多是
/api/list或者/api/houses之类的JSON接口，直接请求它，返回的就是结构化JSON，解析起来比HTML容易一百倍； - 如果找接口困难，用Selenium或Playwright做无头浏览器渲染。但这个方法耗时耗内存，毕设里我不推荐优先使用——只有在确实没有接口、页面又必须动态渲染时才用，而且要控制抓取数量。
抓到的数据先别急着入库，先写成JSON文件或者CSV文件，用Pandas打开看一遍，确认字段完整、类型正确。这一环节我在实操中叫“数据落地前的理智检查”。因为爬虫解析经常出现字段错位，比如把“朝向”解析成了“楼层”，直接用会污染整张表。
3. Django后端：数据要存得住、查得动
爬虫抓下来的数据只是原料，真正支撑起整个系统的是Django的数据模型和查询逻辑。这一章我讲表结构设计、ORM操作中的常见坑，以及如何把数据暴露给前端。
3.1 数据库选型与表结构设计
很多教程推荐默认的SQLite，因为零配置。我的建议是：如果你要交一个能演示、数据量不算太大（比如一两万条以内）的项目，SQLite够用；但如果你抓了几万条以上且后续要连着写带复杂聚合的查询，建议直接用MySQL。因为MySQL在Windows和服务器上都更容易被审查，用Navicat或Redis的可视化客户端调试的时候也更直观。而且答辩时你说“我数据放在MySQL里”通常比“SQLite”听起来更靠谱。
表结构我走了源码里比较标准的方案。核心表叫House，字段包括：
title：房源标题city/district/location：城市、区域、小区位置house_type：户型，如“3室2厅”area：建筑面积（FloatField）toward：朝向floor：楼层信息decoration：装修情况total_price：总价（FloatField）unit_price：单价（FloatField）url：房源链接pid：外部ID，用唯一约束去重created_at：抓取时间
建这个表的时候要注意几个细节：
- 去重：同一套房源在爬虫多次运行后可能会被重复抓到，所以
pid字段要做unique=True，存储时用update_or_create或者自己判断已存在。我在操作中发现update_or_create很省事，一行代码搞定新增和更新，但要避免并发时出现重复，可以在数据库里给pid加唯一索引。 - 索引：
district、total_price这种经常做分组或过滤的字段，建议加db_index=True。虽然数据量不大的时候索引感知不强，但这属于论文里可以写一笔的“性能优化”内容。 - 字段类型：价格和面积一定用
FloatField或DecimalField，不要用CharField。因为从HTML里抓出来的“560万”这种字符串要清洗过滤后转成数字才能存。如果存成字符串，聚合查询的时候就只能做字符串操作，非常痛苦。
3.2 ORM操作：保存、过滤、聚合查询与删除
Django ORM里几个容易出现问题的点，正好对应热搜词里的“django执行查询-删除对象”。
先讲保存。手动构造House对象再save()当然可以，但在爬虫代码里频繁调用，效率不高。更顺滑的做法：
House.objects.update_or_create( pid=item["pid"], defaults={ "title": item["title"], "district": item["district"], "total_price": item["total_price"], ... } )这段代码的逻辑是：如果pid在表里不存在，则新建；如果存在，则更新defaults里的字段。这样爬虫想跑多少次都行，数据不会成倍增长。
再讲查询。这是毕设系统里最核心的能力。整个前端展示的数据，最终都来源于Django ORM的聚合查询。比如“每个区域的平均单价”就可以这样查：
from django.db.models import Avg result = House.objects.values("district").annotate( avg_price=Avg("unit_price") )values("district")按区域分组，annotate(Avg("unit_price"))计算每组单价平均值。返回的结果是一个QuerySet，每一项都包含district和avg_price字段。要让这个结果直接给ECharts用，你只需要转换成JSON：
data = list(result)Django的JsonResponse可以直接序列化，但要注意QuerySet里如果有DecimalField字段，直接序列化会报错，需要先把Decimal转成float。这是很常见的坑。
再讲删除。热搜里有“django执行查询-删除对象”，很多人以为删除对象就是House.objects.delete()——那是清空整张表，非常危险。正确的做法有以下几种：
# 删除单条 obj = House.objects.get(pid="xxx") obj.delete() # 按条件删除 House.objects.filter(district="某区", total_price__lt=200).delete() # 清空表（慎用） House.objects.all().delete()答辩时老师如果问“爬虫数据如果抓错了怎么办”，你要能说出“我可以通过ORM的filter筛选出异常数据，再调用delete删除”，而不是支支吾吾说不知道。
另外在Django中，如果模型定义了外键关联，删除父对象时默认是级联删除或保护删除。但二手房这个场景里表结构简单，基本都是单表，所以delete是直接生效的。要注意的是，如果项目里用了软删除逻辑（加一个is_deleted字段），那ORM的delete方法就不用了，改成更新状态。这个看具体项目，不是必须。
3.3 Django API接口与前端交互
数据可视化页面要的数据不是直接暴露数据库给前端，而是通过Django views返回JSON。最轻量、最省事的方案是JsonResponse。比如我们要一个“城市-平均单价”榜单：
import json from django.http import JsonResponse from django.views.decorators.http import require_GET @require_GET def city_avg_price_api(request): result = House.objects.values("city").annotate( avg_price=Avg("unit_price") ) data = [ {"name": item["city"], "value": round(float(item["avg_price"]), 2)} for item in result ] return JsonResponse({"data": data})这个接口返回的数据结构非常简单，前端ECharts可以直接用。如果你想把数据粒度更细一点，比如“某个城市每个区的二手房挂牌量”，同样的写法，把values("city")改成values("district")，再annotate(cnt=Count("id"))即可。
这里我多说一句：不要给每个页面单独写一个复杂的ORM查询，尽量把一些常用的聚合逻辑抽成函数或自定义管理器方法。比如我在项目里写了几个方法，get_city_avg_price()、get_district_distribution()、get_house_type_ratio()，后续新增接口时只需要调用这些方法，不用重写查询逻辑。这在答辩时是一个很好的“代码组织能力”体现。
如果前端页面不是纯现成的模板，而是你自己写的，建议用Django的模板系统直接渲染一个半静态页面，页面里通过fetch去请求API接口，再做可视化。这样前后端职责分离，演示的时候也更流畅：页面是本地文件，不依赖后端也能看到壳子；后端跑起来之后，再拉取实时数据。
4. 可视化：把数字变成能答辩的图表
4.1 可视化方案选型：ECharts与百度可视化大屏风格
可视化是整个项目里最直观得分的一环，也往往是答辩评委第一眼看的东西。方案选型我建议直接上ECharts，具体原因在第一章讲过。这里我具体展示一下落地方式。
最简单的落地方式：在Django的模板中引入ECharts的CDN：
<script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script>然后在页面里写一个div容器，ECharts初始化以后设置option。如果项目需要离线演示，就把ECharts的js文件下载到本地static目录。
热词里提到“百度可视化大屏”，这个风格即使用ECharts也很容易实现。视觉效果上无非几个特点：深色背景、大标题、多区块排列、科技感边框。你不需要真的去买大屏组件库，Django模板里用CSS Grid或Flex布局把几个图表卡片摆好，背景用#0f0f23这种深色调，图表文字颜色调亮，大屏感就出来了。这个在答辩现场带来的冲击力是很大的。
4.2 核心分析维度与图表映射
数据分析系统的价值在于分析维度，而不是把单价的数字直接铺开。结合热点搜索的关键词，以下维度基本是必做的：
二手房均价走势：横轴时间（按月或按季度），纵轴均价，用折线图展示。这个维度依赖数据里的
created_at字段和unit_price字段，但爬虫抓到的数据是一次性的静态数据，不是时间序列数据，所以要做到“走势”需要用另一种思路：要么在多次抓取后累积历史数据，要么按房龄或挂牌时间推算。用累计多次抓取的数据，把每次入库时间作为时间轴，就可以画出真实的挂牌均价变化。区域二手房均价对比：柱状图或横向条形图，主轴是城市内的行政区，展示各区的均价或者挂牌量。这是最基础、也最有说服力的图。
户型结构分布：饼图或环形图，展示两室、三室、四室及以上房源的占比。用
Count('id')按house_type分组。面积与总价散点图：非常能体现“数据分析”思维的一张图。横轴是面积，纵轴是总价，你可以直观看到线性关系，也可以发现异常点（比如面积很大但价格很低的房源，很可能是别墅或特殊性质房源）。
城市对比雷达图或柱状图：如果抓取了多个城市，可以做一个一线城市与新一线城市的均价对比，分析不同城市的性价比差异。
如果时间允许，再加一个地图热力图，展示某个城市各区域的房源密集度。这个用ECharts的地图扩展实现，但需要GeoJSON数据，对地理数据的处理比较繁琐，演示起来却是全场最醒目的存在。
4.3 数据清洗和其他数据源的合并思路
从爬虫抓到的数据直接进可视化是不行的，因为抓下来的HTML文本往往不是干净的数字。我踩过最典型的坑是：house_type里混着几套表述，比如“3室2厅”“三室两厅”“3室2厅1卫”，如果不统一，分组统计的饼图会出现十几个细碎类别。
我的清洗策略分三层：
第一层是文本清洗。把全角字符转半角、去掉空格和换行、去掉“万”“元/平”等干扰词，统一朝向的写法（“南北”和“南 北”合并成“南北”）。
第二层是类型转换。把total_price从“560万”转成560.0，把unit_price从“45000元/平”转成45000.0。代码很简单，用Python的replace()去掉干扰词再float()。
第三层是异常值处理。比如面积小于3平方米或大于1000平方米的数据，总价为0的数据，直接过滤。也可以用Q对象做个批量过滤：
from django.db.models import Q House.objects.exclude( Q(area__lt=3) | Q(area__gt=1000) | Q(total_price__lte=0) )这里再提一个比较有分析价值的合并思路：把你们学校所在城市的公开住房数据（比如统计年鉴里的平均工资、人口数据）导入另一张表，用均价和工资比做“房价收入比”。这个分析维度在答辩时是加分项，因为你能把“二手房数据”和“社会经济指标”联系起来，比单纯展示价格分布更有深度。
5. 从现象到结论：二手房数据分析的几类产出
很多同学折腾了半天，爬虫也跑了、图表也画了，但论文里“数据分析”部分写出来只是“房价是多少、哪个区贵”。这样论文的高度就不够。我认为至少要有三种可写进论文的分析产出。
5.1 均价走势分析
如果系统运行了两三周，你可以从入库时间这个维度观察挂牌价的波动。比如在年末，房源挂牌价通常会出现小幅下调，因为很多房主为了年底回笼资金，会适当降低挂牌价。这种观察结论要完全靠数据说话：把时间按周切分，计算每周的均价和中位数，再用折线图展示。中位数比均值更有说服力，因为个别高价房源会把均值拉高。
另一个常见分析维度是“房龄与均价的关系”。如果你在详情页抓到了建筑年代，可以按年代分段（2000年以前、2001-2005年、2006-2010年、2011年以后），算每个段位的平均单价。结论通常很明显：房龄越新，单价越高。但二手房市场存在“学区溢价”“地段溢价”，所以最好在同一区域内对比，这样得出“即使在同一区域，房龄仍然是影响价格的重要因子”这样的结论，就更严谨了。
5.2 区域热力与户型结构分析
区域分析用柱状图加地图热力最直观。我用过的一个分析思路是：把每个区的平均单价和挂牌量放在同一张组合图里，左边柱状图是均价，右边折线图是挂牌量。你会看到很有意思的现象：有的区域均价高但挂牌量低，说明供应紧张；有的区域均价低但挂牌量大，说明是刚需集中地。这就是“供需关系”最粗浅但最直观的证据。
户型结构分析则可以和总价段位结合。比如把总价分成200万以下、200-400万、400-600万、600万以上四个档位，然后统计每个档位里户型分布。你可以得到类似“总价400万以下的房源以两居室为主，总价越高三居室占比越大”这样的结论。这类结论来自真实数据，不是拍脑袋说出来的，在论文里非常有价值。
5.3 分析报告怎么写得像“成果”
这一步很关键，也最容易被忽视。很多人的毕设系统里有图、有表，但“分析报告”页面是一堆文字套话，比如“近年来我国房地产市场总体平稳”。这种话没有数据支撑，评委一看就觉得水。
我在项目里专门做了一个“报告生成”模块，把每张图表背后的统计结论用“数据+结论”的方式写死，同时结合图表生成一段描述性的中文说明。比如：“根据爬取数据，A区挂牌均价48200元/平方米，挂牌量341套；B区挂牌均价31800元/平方米，挂牌量525套。A区均价高出B区51.6%，但挂牌量仅为B区的65%，显示A区存在供给紧张状况。”这段文字比干巴巴的图表更有说服力，因为它把数据变成了判断。
要实现这个，你可以把结论模板写在Django的视图函数里，用ORM查询的数据填充模板字符串。代码层面上不复杂，但对“数据分析”的定义落实得很到位。
6. 答辩与技术追问准备：这些问题答不上来很吃亏
6.1 关于爬虫合规与技术边界的回答思路
答辩时极大概率被问：你的爬虫是否合法？怎么证明你的爬虫没有影响目标网站？这个问题不能含糊。你事先要做三件事：
- 在论文里说清楚“数据用于毕业设计学习交流，不用于商业用途”；
- 在代码里展示“遵守robots协议、控制请求频率、不强刷、不并发攻击”；
- 在口头答辩时说“我在请求间设置了随机延时，限制抓取速率，仅抓取公开挂牌数据，未涉及个人隐私”。
另外一个可能被追问的技术点是“439/404/403的处理”。你需要能解释：请求被限流时返回的429怎么处理、页面未找到时返回404怎么跳过、权限受限时403怎么放弃。把重试机制和异常捕获写进代码，而不是让爬虫程序崩溃退出。这是成熟爬虫和玩具爬虫的一个分界线。
6.2 关于性能与分布式扩展的回答思路
评委老师如果追问“你这套系统能不能扩容”，他并不是真要你去扩容，而是想听你对架构的理解。回答思路可以有：
- 爬虫层：可以从单线程升级为线程池或异步协程，也可以拆分为分布式爬虫，用消息队列（Redis）做任务分发，但前提是目标网站允许且频率可控；
- 数据层：单表数据量大以后，可以按城市分表，引入索引优化查询，或者引入缓存（比如用Redis做可视化接口的缓存）；
- 展示层：ECharts大数据量渲染时，可以只传聚合后的数据，而不是原始数据；还可以做前端分页。
不用真的把这些都实现了，但表达出“我知道从单机到分布式要改哪些点”，足以体现能力储备。如果按热词里“分布式爬虫”的方向再延伸一点，你可以提到Scrapy-Redis：把请求去重集合和任务队列放到Redis里，实现多台机器协作爬取。这是行业里成熟的做法，说出来显得不业余。
6.3 实用技巧：Django后台与调试经验
整个系统开发过程中，以下几个经验我觉得比任何一个语法点都值钱：
第一，Django Admin是调试利器。你辛辛苦苦爬了数据，想知道字段是不是都对了，不需要写SQL查，直接在Admin里打开House表即可。你需要在admin.py里注册模型：
from django.contrib import admin from .models import House @admin.register(House) class HouseAdmin(admin.ModelAdmin): list_display = ("title", "district", "unit_price", "total_price", "created_at") list_filter = ("city", "district") search_fields = ("title", "location")这样你在开发过程中能非常直观地看到数据长什么样，也能快速过滤出异常字段。
第二，任何ORM聚合查询之前，先在Python的shell_plus或普通manage.py shell里跑一次。如果查询出错，是ORM写错还是数据类型问题，在shell里调试比改完前端再刷新看结果高效得多。比如Avg返回的是Decimal，JSON序列化时报错，你就可以在shell里提前发现这个问题，不用等前端黑屏。
第三，数据可视化接口要做容错。如果爬虫还没跑、数据库是空的，那么可视化页面应该显示“暂无数据”，而不是直接报错。我实践的写法是在views里判断结果为空的场景，返回一个空数组或固定的占位数据。这样演示期间不会出洋相。
第四，Django的CSRF防护会在你调试POST接口时“咬你一口”。毕业设计里如果完全自己写POST表单，CSRF会要求表单里必须带{% csrf_token %}。如果你用AJAX提交，需要在请求头里加X-CSRFToken。这是热词里“java controller层如何防护防止爬虫”这类问题的Django对照版——回答思路是：Django自带CSRF，不仅防护CSRF攻击，在某种程度上也能防止跨站请求伪造。不过要注意，CSRF防护并不是用来防爬虫的，防爬虫主要靠请求频率控制、UA校验、验证码等手段。答辩时别把这两个概念混在一起。
第五，时区问题。Django项目的TIME_ZONE设置为'Asia/Shanghai'，USE_TZ保持True，入库时间才会是你本地时间。否则你分析“一天中的挂牌高峰”时，会发现数据偏移了8个小时，很难调。
我自己做完这个项目之后最大的感受是：这个题目的价值不在于“爬了多少数据”，而在于你学会了“从数据采集到数据决策”的完整闭环。有很多项目看起来功能很炫，但数据是写死的；而这个项目的数据是活的，是你亲手从平台采集、清洗、建模、展示出来的，这才是真正的数据分析。
如果你现在刚拿到这个题目，我的建议是：先花一天时间把数据链路跑通，哪怕只抓一个城市一百套房源，哪怕页面暂时没有，先把Django的ORM和API调通。这个最小闭环一旦建立，剩下的事情都是填充数据、丰富图表和优化细节。不要一上来就追求全国几十个城市、几万套房源的大场面，那是给自己挖坑。
最后分享一个我从这个项目里摸出来的小技巧：抓的数据不要只为了应付页面展示而存，尽量把原始抓到的JSON文件也保留一份。后面写论文、补图表、复盘数据分布的时候，你会感谢自己当时没删掉这些原始文件。它们还能帮你验证“清洗前后数据的变化”，这本身也能写进论文的“数据预处理”章节里。
