做毕业设计那阵子，我最怕的就是选题太“水”。后来我把目标锁定在“Python租房数据智能分析平台”上——这个名字一听就包含了好几层硬核技术：Python、Django框架、Requests爬虫、数据可视化、大数据分析，整套做完，论文有得写，演示有得看，答辩也有得聊。这篇内容不吹不黑，把我从数据采集、数据库设计、可视化大屏到大模型接线的完整路径拆开讲，源码结构也梳理给你，正在做毕设或者想练手数据分析全流程的朋友可以直接照着抄思路。
1. 选题与架构设计：租房数据平台为什么值得做
1.1 数据源公开且字段丰富，毕设最怕“没数据”
我见过太多选题死在“没数据”上。做企业级项目需要商业数据，做算法类需要大规模标注集，而租房数据恰恰是互联网上最容易获取、结构相对规整、分析维度极其丰富的公开数据。一个房源详情里就绑定了户型、朝向、楼层、面积、价格、位置、区域、商圈、地铁距离、挂牌时间、小区名等二十几个字段，天然就是一份干净的教学级数据集。
更关键的是，租房数据有真实的时间维度和空间维度。我一共抓了大约两万多条样本，放在MySQL里也就几十MB，完全不挑机器，普通笔记本就能跑。可你要是把它改成“全国二手房交易分析”或者“股票数据分析”，数据源合规性和采集难度都会上一个台阶，毕设周期根本兜不住。所以我给身边人的建议一直是一句话：毕设选题先问自己三个问题——数据能不能合法拿到？技术栈覆盖面够不够广？演示效果能不能一眼看懂？租房数据平台三条全中。
1.2 技术栈选型的取舍逻辑：Django + Requests + ECharts
这题的核心不是“哪个框架最强”，而是“哪个组合最合适”。我最终定下来的是Django框架 + Requests库 + ECharts可视化，外加后期接一个大模型API做智能分析，理由很实在：
- Django提供完整的ORM、Admin后台和模板引擎。我不需要额外写前端框架，Django的template里直接嵌HTML和ECharts就能把页面撑起来，省去前后端分离的部署复杂度。
- Requests是Python最经典的HTTP客户端库。相比Scrapy，Requests的代码更直观，每一行都在明明白白告诉评委“我发出了一个HTTP请求、拿到了返回内容、解析了什么字段”。毕设答辩时老师问“你的爬虫原理是什么”，你可以很从容地把HTTP请求过程从头讲到尾。
- ECharts的图表种类丰富，柱状图、折线图、饼图、散点图、地图都有现成模板。最重要的是它在浏览器端渲染，对服务器压力小，做动态交互也方便。
选型阶段我没用前后端分离（Vue + DRF + Nginx那套），主要原因有两个：一是毕设周期有限，二是技术栈越多，联调阶段出Bug的概率越大。先跑通“爬虫→入库→查询→渲染”这条最短链路，再考虑要不要扩展成前后端分离架构，这才是稳妥节奏。
1.3 整体业务链路：从爬虫到大模型的四层结构
平台整体上分四层，我画在论文架构图里就是典型的“数据采集层 → 数据存储层 → 业务分析层 → 展示交互层”。
数据采集层用Requests抓取租房平台的列表页和详情页，拿到JSON或HTML之后做字段解析和清洗，最后落库。存储层初期用SQLite，等数据量超过两万条后我换成了MySQL，避免并发写入时出现数据库锁问题。业务分析层这一层全部写在Django的app里，对外暴露一组JSON接口，比如按区域求均价、按户型统计数量、按面积段分布等。展示层就是ECharts画的大屏页面，包含首页总览、区域价格地图、户型占比、价格走势等模块。大模型的接入放在分析层的上层，负责房源描述生成和简单问答。
这套链路最大的优点是“每一层都有干货”，论文每一章都有实际代码支撑，不是空谈框架。
2. Requests爬虫：房源数据采集的实操细节与反爬应对
2.1 先搞清楚目标站点的页面规律再写代码
写爬虫最忌讳一上来就敲代码。我第一天通宵写了个脚本，结果发现目标站点的列表页是动态加载的，直接用Requests拿不到房源列表，白白浪费了半宿。第二天老老实实打开浏览器开发者工具，把网络请求逐个看了一遍，才找到真实的接口地址。
实际操作套路是这样的：
- 打开目标租房网站的列表页，按F12进入开发者工具，切到Network选项卡；
- 刷新页面，重点看XHR请求，找到返回JSON数据的那个接口地址；
- 观察接口的参数规律，比如页码参数、城市参数、租金范围参数；
- 用Requests模拟该接口请求，带上必要的请求头，验证能否拿到数据；
- 如果接口有加密参数，就退而求其次，直接抓列表页HTML，用正则或解析库提取字段。
我抓的那批数据就是用接口方式拿的，返回的是JSON，字段直接可用，省去了HTML解析的各种坑。但你要注意，不同站点的接口风格差别很大，有的需要带签名参数，有的要携带Cookie。这种场景下我的兜底方案是：先抓列表页的静态HTML，解析每个房源的详情页链接，再逐个请求详情页。速度慢一些，但稳定性好，适合毕设这种对实时性要求不高的场景。
2.2 请求头伪装与请求频率控制：反爬的正面应对
我的Requests写法分三块：请求头设置、Session保活、频率控制。请求头里面最关键的是User-Agent和Referer，很多站点对缺少这两个字段的请求直接返回403。下面这个是我当时的基础模板：
import requests import time import random HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 " "(KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36", "Referer": "https://www.example.com/zufang/", "Accept": "application/json, text/plain, */*", "Accept-Language": "zh-CN,zh;q=0.9", } session = requests.Session() session.headers.update(HEADERS) def fetch_list(page): url = "https://www.example.com/zufang/pg{}/".format(page) resp = session.get(url, timeout=10) if resp.status_code == 200: return resp.json() else: print("请求失败，状态码：", resp.status_code) return None关于频率控制，我的策略是每次请求之间随机sleep 1到3秒，不要用固定间隔，否则很容易被识别为脚本。数据量不大时，单线程就够了，完全不用上多线程或者异步。如果你打算抓几万条数据再考虑线程池，但毕设场景建议控制在一万条以内，既够分析又不用处理太复杂的反爬问题。
另外有一件事必须强调：爬虫一定要遵守目标网站的Robots协议，控制请求频率，不要影响网站正常运行，数据仅用于学习研究。论文里最好专门写一节“数据采集的合规性说明”，答辩时老师很可能会问。
2.3 字段清洗：脏数据永远比你想的多
抓下来的原始数据不能直接入库，我统计了一下，原始数据里大约有15%的字段存在问题。常见情况包括：价格字段里有“元/月”这种单位后缀；面积字段有“平米”文字；朝向有的是“南北”，有的是“南 北”带空格；楼层字段格式五花八门；部分房源缺经纬度坐标。
我写了一个统一的清洗脚本，核心逻辑是正则匹配加类型转换：
import re def clean_price(raw): num = re.search(r"\d+", str(raw)) return int(num.group()) if num else 0 def clean_area(raw): num = re.findall(r"\d+\.?\d*", str(raw)) return float(num[0]) if num else 0.0 def clean_orientation(raw): if not raw: return "未知" return raw.replace(" ", "").strip()清洗脚本跑完，再统一做一次去重，以“小区名+户型+面积+价格”作为唯一键，删掉重复数据。最终落库时字段类型要规范化，比如价格用INTEGER、面积用FLOAT、经纬度用DECIMAL。很多人拿到爬下来的数据直接往数据库里塞，后期做统计时会发现各种类型报错，这一步别偷懒。
3. Django后端与数据建模：从爬虫数据到业务字段
3.1 项目初始化与模型设计
Django部分我建议用虚拟环境安装，避免污染系统Python环境。完成环境隔离之后，创建项目和应用，然后重点设计数据模型。我的RentHouse模型是这样设计的：
from django.db import models class RentHouse(models.Model): title = models.CharField(max_length=200, verbose_name="标题") district = models.CharField(max_length=50, verbose_name="区域") bizcircle = models.CharField(max_length=100, verbose_name="商圈", blank=True) community = models.CharField(max_length=100, verbose_name="小区") house_type = models.CharField(max_length=50, verbose_name="户型") area = models.FloatField(verbose_name="面积") price = models.IntegerField(verbose_name="租金") orientation = models.CharField(max_length=20, verbose_name="朝向") floor = models.CharField(max_length=50, verbose_name="楼层") publish_date = models.DateField(null=True, verbose_name="挂牌日期") source_url = models.URLField(unique=True, verbose_name="来源链接") created_at = models.DateTimeField(auto_now_add=True, verbose_name="入库时间") def __str__(self): return self.title有几个设计细节值得说：source_url设置成unique，是为了防止同一房源被重复抓取和重复入库；publish_date允许为空，因为有部分房源详情页不公开挂牌日期；area和price单独设成数值类型，是为了后续ORM聚合计算方便。你要是把价格存成VARCHAR，后面做均价统计就要先转换一趟，纯属给自己加工作量。
3.2 批量导入：用bulk_create代替逐条循环
数据清洗完成后，导入数据库时千万不要用for循环逐条save，十万条数据你能等到怀疑人生。正确做法是用Django ORM的bulk_create批量导入，我实测一万条数据导入时间从分钟级降到秒级：
from sync_data.models import RentHouse def import_house_list(clean_rows): objs = [ RentHouse( title=row["title"], district=row["district"], community=row["community"], house_type=row["house_type"], area=row["area"], price=row["price"], orientation=row["orientation"], floor=row["floor"], publish_date=row.get("publish_date"), source_url=row["source_url"] ) for row in clean_rows ] RentHouse.objects.bulk_create(objs, batch_size=500) print(f"本次导入 {len(objs)} 条数据")如果你是从CSV文件导入，还可以用pandas的read_csv先读进来，转成字典列表后再调上面的函数。我当时就是写了一个management command，放在Django应用里的management/commands/import_data.py，这样可以用python manage.py import_data --file=xxx.csv一键完成导入，论文里写“实现了命令行数据导入工具”也算一个小亮点。
3.3 聚合查询接口：给前端提供干净的JSON
可视化页面需要的数据不能靠模板里直接查数据库，那样代码太乱。我的做法是写一个只读API视图，用Django的ORM聚合函数处理数据后返回JSON。这块是Django最值钱的地方，聚合统计代码非常简洁。
from django.db.models import Avg, Count, Max, Min from django.http import JsonResponse from sync_data.models import RentHouse def district_stats(request): stats = RentHouse.objects.values("district").annotate( avg_price=Avg("price"), max_price=Max("price"), min_price=Min("price"), total=Count("id") ).order_by("avg_price") data = { "categories": [item["district"] for item in stats], "avg_prices": [round(item["avg_price"], 2) for item in stats], "total_counts": [item["total"] for item in stats], } return JsonResponse(data)同理，户型占比、面积段分布、价格分布这几类统计都可以用类似方式写。把所有接口集中在urls.py里统一配置，前端直接fetch这些JSON接口渲染图表，职责清晰，答辩时也好讲解。这里我不推荐用Django REST Framework，因为毕设只需要只读接口，自带JsonResponse完全够用，少装一个依赖就少一个报错源。
4. 可视化大屏与数据分析维度：把数据变成人话
4.1 先定分析问题，再选图表
做可视化最怕“为画图而画图”。你在论文里写“我用了柱状图、折线图、饼图、散点图”，老师一句“这些图表分别说明什么问题？”就能把你问住。所以我在做页面之前先列了五个分析问题：
- 哪些区域的平均租金最高？（区域均价Top10，用横向柱状图）
- 租金价格分布呈现什么形态？（价格区间频次分布，用直方图或者柱状图）
- 户型与价格之间是什么关系？（不同户型的平均租金，用箱线图或柱状图）
- 面积和总价之间是否存在相关性？（用散点图）
- 各区域挂牌房源数量如何？（用地图或饼图）
每个问题对应一张图，每张图在页面上都有标题和图例说明，评委扫一眼就能看懂你的分析逻辑。
4.2 大屏页面布局与ECharts实战
大屏页面我直接用Django模板渲染，整体用CSS Grid布局分成上中下三行：顶部展示平台名称和核心指标卡片（房源总数、平均租金、最高租金、覆盖区域数），中部左边是区域均价柱状图，中间是价格分布图，右边是户型占比饼图，底部放面积-价格散点图和区域房源数量排行。页面加载后统一fetch接口，再初始化ECharts。
ECharts接入很流畅，只需要在base模板里引入echarts.min.js，然后在页面里声明容器和脚本。以区域均价柱状图为例：
<div id="districtChart" style="width:100%;height:400px;"></div> <script> fetch('/api/district_stats/') .then(response => response.json()) .then(data => { var chart = echarts.init(document.getElementById('districtChart')); chart.setOption({ title: { text: '区域平均租金排行(元/月)' }, tooltip: { trigger: 'axis' }, grid: { left: '3%', right: '4%', bottom: '3%', containLabel: true }, xAxis: { type: 'value', name: '元/月' }, yAxis: { type: 'category', data: data.categories.reverse() }, series: [{ type: 'bar', data: data.avg_prices.reverse(), itemStyle: { color: '#409EFF' } }] }); }); </script>这种横向柱状图在区域名称较长时效果最好，比纵向图看着舒服。我自己测试下来，ECharts渲染几千个点完全无压力，唯一要注意的是图表容器必须在DOM渲染完成后初始化，所以脚本要放到页面底部，或者用window.onload包裹。
4.3 数据分析结论：图表下面一定要有解读
可视化页面不是终点，论文里要写“基于可视化图表得出的分析结论”。我根据实际抓到的数据得出了几条很有价值的信息：
- 租金与面积整体呈现正相关，但单价与面积负相关，大面积房源存在明显的“面积溢价折价”现象；
- 地铁沿线房源价格明显高于非沿线，同样户型的平均租金差距在20%到30%；
- 一居室和两居室的单位面积租金最高，三居室以上的单位面积租金逐步下降；
- 热门商圈房源量集中，但价格离散程度极大，存在明显的长尾效应。
每条结论我都在大屏配了对应的图表，答辩时把这套“结论+图表”讲下来，老师基本不会再追问“分析和可视化在哪”。还有个加分项，我会在页面下方放一个数据说明卡片，注明数据采集时间和数据条数，虽然不起眼，但能体现你的严谨性。
5. 大模型融合：房源描述生成与价格趋势预判
5.1 毕设里怎么切大模型最加分
大模型现在确实是热点，但如果只是简单调API聊天，评委只会觉得你是“蹭热点”。我调研了一圈，给平台设计了大模型的两个落地场景：
第一个是智能房源摘要生成。爬虫拿到的是结构化字段，普通用户看一串字段信息不直观，大模型可以根据区域、户型、价格、面积、朝向、楼层这些字段，生成一段自然、口语化的房源推荐语。
第二个是租房问答助手。用户提出“XX小区附近一居室月租大概多少”“预算3000在A区能租到什么房子”这类问题，平台先从数据库里检索匹配数据，再让大模型组织成自然语言回答。这一步的关键是“先检索后生成”，也就是RAG的思路，而不是让模型瞎编数据。毕设环节做好第一个场景基本就够惊艳了，第二个可以做效果展示。
5.2 提示词模板：字段转文案的工程化写法
大模型结果质量高不高，70%取决于提示词设计。我试过的提示词模板可以直接参考：
你是一个专业的房屋租赁文案编辑。请根据以下结构化字段，生成一段60字以内、 符合中文表达习惯的房源推荐语，突出性价比和适合人群。 字段信息： 区域：{district} 小区：{community} 户型：{house_type} 面积：{area}平米 月租：{price}元 朝向：{orientation} 楼层：{floor} 要求： 1. 不要出现“优质”“绝佳”等空泛形容词 2. 适当强调房源的实际优势，比如价格低于同区域均值或面积较大 3. 结尾给出适合人群建议实际调用时，我先从数据库里取Top10的房源记录，拼成上面模板再请求大模型接口。实测下来，不同模型生成的描述质量差距挺大，但做毕设够用了。要注意的是，调用大模型API的代码不要写在Django视图中同步执行，因为一次请求可能要几秒钟，页面会卡住。我的方案是写一个Celery定时任务，每天晚上批量生成房源描述存入一个独立的description字段里，页面直接读库展示。
5.3 部署细节与成本控制：别让API费用吃穷你
大模型API按token计费，毕设阶段一定要控制成本。我的经验是：先用小模型做测试，调通提示词后再考虑更高级的模型；单次生成限制输出长度，比如max_tokens设置为200；对同一房源只生成一次，用字段是否为空判断是否跳过。整个项目大概生成了3000条房源描述，控制在几十块钱以内，属于完全可以接受的范围。
代码层面的调用建议封装成独立模块，不要散落在视图里：
def generate_house_description(house): prompt = build_prompt(house) try: response = llm_client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": "你是一名严谨的租房数据分析助手。"}, {"role": "user", "content": prompt} ], max_tokens=200, temperature=0.7 ) return response.choices[0].message.content.strip() except Exception as e: print("大模型调用失败：", e) return ""如果用国内大模型服务就在他们的控制台创建API Key，用国外模型也是同样的HTTP请求逻辑，核心就是模型名、API Key、消息上下文这三个参数。安全方面，API Key千万不要写死在代码里，我用的是环境变量方式加载，并且把.env文件加入了.gitignore，避免上传到代码仓库泄露。
6. 部署落地与服务器联调：从本地跑通到外网可访问
6.1 本地联调最容易忽略的两个点：静态文件和ALLOWED_HOSTS
本地开发时用Django自带开发服务器一切正常，但准备部署上服务器时会遇到两个经典问题。第一个是静态文件404，因为Django生产模式下默认不提供静态文件服务，需要收集静态文件并交给Nginx托管，或者用WhiteNoise这个中间件。第二个是访问IP地址时报DisallowedHost错误，需要在settings.py里配置ALLOWED_HOSTS，把服务器IP和域名加进去。
我在本地联调时采用的方法是：开发阶段直接在settings.py里写ALLOWED_HOSTS = ["*"]，方便自己用局域网IP测试手机端效果；准备部署时再改成具体域名或IP，保证安全性。静态文件方面，为了省事，我用了WhiteNoise一行配置解决，这样就不用单独配Nginx静态路径了，对于毕设演示足够。
6.2 Gunicorn + Nginx的经典部署组合
我部署方案用的是Gunicorn作为Django的WSGI服务器，Nginx做反向代理，这套组合最稳。先安装并启动Gunicorn：
pip install gunicorn gunicorn -w 4 -b 0.0.0.0:8000 config.wsgi:application这里-w 4表示4个worker进程，小内存云服务器建议改2个，否则容易OOM。Nginx配置里把/路径代理到8000端口，同时处理静态文件。整套配置跑通后，用systemctl管理Gunicorn服务，确保重启服务器后自动拉起应用。
6.3 数据更新策略：别手动跑爬虫了
数据有时效性，论文里最好写“实现了定时自动更新”。我用的是最简单的crontab方案，每天凌晨两点执行爬虫脚本，先抓新数据，再清洗入库，最后更新大屏数据：
0 2 * * * cd /home/ubuntu/rent_analysis && /home/ubuntu/venv/bin/python manage.py crawl_update >> logs/crawler.log 2>&1这个crontab命令解释一下：每天凌晨2点进入项目目录，用虚拟环境里的Python执行自定义管理命令。这里我写了一个crawl_update命令，内部逻辑是：抓取数据 → 清洗 → 去重 → 增量入库 → 更新描述生成。上线之后我每天检查一次日志，只要log文件里没有异常就说明系统在健康运行。比起手动执行，这种自动化方案在答辩时能给你加分不少。
7. 踩坑总结与毕设答辩：我走过的弯路你可以绕开
7.1 三个典型坑的完整排查过程
第一个坑是SQLite数据库锁问题。我最初图省事用SQLite，结果爬虫批量写入和前端聚合查询同时发生时，经常报database is locked。排查过程比较曲折，我一开始以为是代码问题，单步调试了很久才发现是并发写锁。后来把数据库切成MySQL，用INSERT IGNORE配合唯一索引做去重写入，问题彻底解决。所以数据量超过一万条，别犹豫，直接上MySQL。
第二个坑是ECharts图表初始化时容器宽度为0。当时图表怎么都不显示，打开浏览器开发者工具才发现容器是display:none，初始宽度为0。解决方案是把初始化代码放到窗口load事件之后执行，或者等tab切换完成再初始化图表。
第三个坑是大模型API调用超时。一次生成3000条房源描述，如果逐条同步请求，几个小时都跑不完，而且中途还经常断连。我的解决方案是加retry机制，每次超时3秒则重试3次，同时用批量并发限制，比如同时最多10个请求，实测速度提升了近10倍。这块在论文“系统优化”章节里是一个很好的篇幅点。
7.2 答辩高频问题与应对思路
毕设答辩老师一般会围绕三个方向提问：技术选型、代码真实性、业务理解。技术选型方面最常被问的是“为什么用Requests不用Scrapy”。我的回答思路是：毕设数据量在万级规模，Requests单线程加控制延迟完全够用，且代码的可读性和可控性更高；Scrapy更适合大规模分布式采集，但需要额外引入Twisted异步框架，对于这个项目来说属于过度设计。如果你回答的时候再补一句“数据量过万时我也对比过Scrapy的采集效率”，效果会更好。
代码真实性方面，老师会看有没有业务逻辑漏洞。比如数据一致性问题、异常处理机制、API密钥安全等。我在代码里故意设计了两处亮点：一处是在批量导入前用transaction.atomic()包裹事务，保证部分失败时数据不残留；另一处是把所有外部调用的异常都封装到统一的日志体系里。这两点虽然代码量不大，但体现了工程思维。
业务理解方面的高频问题是“你的分析结果能说明什么真实租房问题”。这里一定要把大数据演化的几个关键结论背熟，配合平台页面上的可视化结果进行呼应。比如“地铁对租金的溢价影响”这种结论，就要能现场解释清楚从哪个图表看出来的。
做完整套平台再回头看，这个项目的技术含量并不在于用了多少高大上的算法，而是把一条“数据采集-存储-分析-展示-智能应用”的全链路走通了。我在实际操作中最深的体会是，文档写得再多都不如自己把爬虫脚本跑一遍、把数据库表建一遍、把可视化页面调通一遍，踩过的坑才是真正长在自己身上的能力。接下来你可以从爬虫模块开始动手，跑通一遍数据采集，再逐步往Django后端迁移。这套思路不光适用于租房数据，换成二手房、招聘、商品评论这些同样公开的数据源，整个框架几乎可以平移到新的领域。
