今年的毕业论文季又到了，去年有个学弟找我聊他的毕设选题，想做“租房数据分析”，但被导师反问了一句：你的系统到底在“分析”什么？如果只是把爬下来的数据用表格展示一遍，那不叫数据分析，叫搬运工。当时他拿不准，跑来问我到底应该怎么把爬虫、后端、可视化这三条线捏合成一个能打的毕设项目。我把这个题目从数据采集到部署答辩整个链路拆开讲了一遍，今天整理出来分享给正在做类似选题的同学。
这个项目标题看着长，其实本质就一件事：**用Python抓取全国租房公开数据，清洗整理后存入数据库，再用Django做后端接口，最后通过Echarts把分析结果可视化展示出来。**它不是一个纯算法项目，也不是一个纯Web项目，而是一条完整的“数据加工链路”。你抓数据、懂数据、展示数据，这三步每一步都有独立的考核点，组合起来就成了一个体系完整、能讲出技术深度的毕业设计。
很多同学一上来就纠结“我要不要用机器学习算法预测房价”，我的建议是先把整条链路跑通，再考虑锦上添花。链路的每一步都有它自己的坑，没有跑通之前，算法预测只会让你的项目变成一个永远调不完参的坑。下面我会按照实际开发的顺序，把这个项目的每个环节拆开讲清楚，包括我踩过的坑和后来总结出的经验。
1. 这个毕设的本质：一条完整的数据加工链路
1.1 四个模块不是选择题，而是流水线
你在标题里看到“爬虫+大数据+可视化+Django”，很容易把它们当成四个并列的技术点，这是做这个项目最大的误区。实际上它们是一条流水线上的四个工位：
- 爬虫负责原材料采购——把散落在各平台的租房公开信息抓取下来；
- 数据清洗负责质检——爬下来的数据一定会有缺字段、格式错误、重复值等问题，不处理就是垃圾进垃圾出；
- Django后端负责仓储和物流——把清洗好的数据存进数据库，通过接口把数据按需发给前端；
- Echarts可视化负责把数据“翻译”给用户——让非技术背景的人也能看懂区域租金分布、价格走势、户型结构。
这个视角非常重要，因为毕业设计的答辩提问几乎都围绕一件事：**你为什么要这样设计？**如果你能说清楚“我是按数据处理的生命周期来划分模块的”，回答就已经赢了一半。同时你也会发现，这个项目的核心难点其实不在某一个单点技术上，而在“模块之间的衔接”上——爬虫存下来的数据格式能不能被后端直接读取，后端返回的JSON结构能不能让前端不费劲地渲染，这些才是真正花时间的地方。
1.2 这个项目适合什么基础的人，每个阶段学什么
如果你现在会Python基础语法、会一点pandas的DataFrame操作、见过Django的MTV结构，那这个项目完全可以当主力毕设做。它的优势在于：技术栈是经典组合，网上参考多，不容易卡死在某个点上；而每一层的复杂度又可以按自己的水平调节。
- 爬虫层：入门能做requests+BeautifulSoup，进阶可以加Scrapy框架、代理池、登录态模拟；
- 数据处理层：入门能做pandas去重和缺失值填充，进阶可以做统计分析、相关性分析、时间序列建模；
- 后端层：入门能写一个返回JSON的View函数即可，进阶可以加权限认证、缓存、异步任务；
- 前端层：入门能套Echarts官方示例改改配置项即可，进阶可以自己定制地图、联动筛选、大屏动效。
这个项目最舒服的地方在于它的“天花板”足够高，但“地板”不算高。哪怕你只做到入门版，把整条链路走通，提交一个能演示的系统，也完全符合毕设的工作量要求了。
2. 爬虫层：租房数据的获取策略与反爬应对
2.1 数据源选择：为什么从公开页面而不是App入手
对于租房数据，目前常见的公开数据源是几类大型房产信息平台的网页端。做毕设的时候，我强烈建议你首选网页端页面，而不是App抓包，原因有三个：第一，网页端数据直接嵌在HTML或者轻量接口里，用requests就能拿到，不需要破解App的加密参数；第二，网页端的字段信息更完整，标题、户型、面积、朝向、楼层、小区名、行政区、价格这些变量基本都在；第三，网页端的页面结构相对稳定，即便偶尔调整，改动成本也可控。
那具体怎么选城市和范围呢？标题里说的是“全国”数据，但实际操作上不建议一上来就抓全国。我的做法是先锁定20个左右核心城市：一线、新一线、主要省会各挑几个，然后每个城市抓取1到3个主要城区的租房列表和详情页。这样既撑得起“全国”两个字，又不需要让自己的电脑连续跑几天几夜。毕设最重要的是可控，你可能被问“为什么只选了这些城市”，答一句“考虑到数据规模和分析维度，我选取了能代表不同经济发展梯度的样本城市”就非常合理。
2.2 请求策略：频率、UA、重试与代理的取舍
爬虫部分最容易被问，也最暴露水平的地方，其实是请求策略。很多新手一上来就是for循环里直接requests.get，跑不到50条就被封了IP。这里不是教大家对抗平台限制，而是分享一些做正规爬虫时需要遵守的基本规范：
- 必须设置合理的请求间隔：我写的是每个请求之间随机sleep 2到5秒，并且在代码里做成了可配置项。这不是胆小，而是爬虫的基本礼仪。再加上你要存到数据库、分析质量，数据本身不需要十万火急；
- 必须伪装User-Agent：requests默认的UA是Python-requests/x.x，一看就是程序。我准备了一个UA池，里面放十几种常见浏览器的UA，每次请求随机取一个，并在requests.Session里统一管理Cookie；
- 必须设置超时和重试：租房平台偶尔会有响应卡顿或返回异常，我习惯给每个请求设置timeout=10，并对失败的请求做最多3次重试，重试间隔逐次递增。这一步能省掉你半夜爬起来看程序挂没挂的烦恼；
- 代理不要乱用：免费的公开代理其实质量很差，很多时候比直接连还慢。我的建议是在本地跑毕设数据量不需要太大，做好频率控制和UA伪装就够了。如果真到了需要代理的规模，也应优先使用正规云服务商的按量付费代理，而不是免费资源。
还有一点是必须写在代码注释里的：**只采集公开可访问的数据，不碰需要登录才能看到的信息，且不对平台服务器造成压力。**答辩时如果老师问“你有没有遵守robots协议”，你要能明确回答出你采集的是各平台公开页面，并且设置了合理频率控制。
2.3 解析与字段提取：结构化数据是后面一切的地基
请求到了HTML之后，接下来是解析。这一步我最开始用了正则，写起来很痛苦，后来换了BeautifulSoup + lxml解析器，舒服很多。核心思路是：先用浏览器的开发者工具定位到你需要的字段在哪个标签结构里，然后写对应的CSS选择器去提取。
租房数据必抓的字段，我列一份清单供参考：
| 字段 | 说明 | 是否必须 |
|---|---|---|
| 城市 | 数据所属城市 | 是 |
| 区域 | 所在行政区 | 是 |
| 小区/商圈 | 小区名称或商圈名 | 是 |
| 标题 | 房源标题 | 是 |
| 户型 | 几室几厅 | 是 |
| 面积 | 平方米 | 是 |
| 朝向 | 南北、东西等 | 否 |
| 楼层 | 总楼层/所在层 | 否 |
| 租金 | 元/月 | 是 |
| 发布时间 | 挂牌时间 | 否 |
| 链接 | 详情页URL | 是 |
字段提取的原则是：**能多抓的字段就多抓，宁可存下来不用，不要等后面分析发现缺字段再回去补爬。**我第一版就漏了“朝向”字段，结果后面做户型分析的时候想用但数据已经是过去式了，只能重新补爬，时间成本很高。
另外，解析完数据后不要直接入库，先打印几行看看格式。比如价格字段有的平台是“4500元/月”这种带单位的字符串，有的平台直接是“4500”，面积也有“45㎡”和“45平”的区别。这些格式问题属于数据清洗的范畴，但在解析层就顺手统一，能省后面不少事。
3. 数据清洗与预处理：让十万条数据“可用”的关键步骤
3.1 脏数据长什么样：真实爬取数据常见问题
很多同学把爬虫写完、数据抓下来，就觉得大功告成了。实际上爬下来的数据是“原矿”，不经过选矿根本没法用。我自己在真实抓取过程中遇到的脏数据主要有这么几类：
- 重复记录：同一个房源链接可能被同一个城市的不同列表页重复收录，直接导致后面统计量虚高；
- 缺失字段：有的房源不填朝向，有的不填楼层，面积偶尔也会空着；
- 格式不统一：租金有“4500元/月”“4.5千/月”“4500”三种写法，面积有“45㎡”“45平”，楼层有“低楼层/共18层”“第5层”，五花八门；
- 异常值：租金几块钱或者几十万的、面积1平米或者9999平米的、楼层是“地上999层”的，这些明显不属于正常租房范围；
- 城市字段混淆：平台会把不同城市城区的房源混在一个列表接口里，需要根据URL或接口参数二次确认城市归属。
不要觉得这些是小事，在分析阶段你会发现，**一份干净的数据和一份脏数据，得到的结果图可能完全是两个故事。**你做的可视化是为了辅助发现规律，如果数据源本身就错，那结果就是“垃圾进，垃圾出”。
3.2 pandas清洗流水线：去重、缺省、类型转换与异常过滤
数据处理我用的pandas，整条清洗逻辑可以按下面的顺序写成一个可复用的脚本：
第一步：去重。以“链接”字段为主键，drop_duplicates(subset=['link'], keep='first')。如果某些平台没有详情链接，可以用“城市+小区+户型+面积+租金”拼接一个唯一标识来去重。
第二步：缺失值处理。先按字段维度统计缺失率。缺失率低于5%的字段，可以用众数或中位数填充；缺失率适中但字段本身很关键（比如面积），可以选择直接删除该行；完全不重要的字段（比如楼层），可以直接保留缺失。注意，填充的时候要有依据，比如朝向缺失我就用整列众数填充，因为“南北通透”在租房里最常见；而面积缺失不能随便填，我选择删除整行，因为面积对价格分析太关键了。
第三步：类型转换。把租金、面积从字符串变成数值，把发布时间变成datetime类型。这里有个小技巧：清洗字符串统一用str.replace()把“元/月”“㎡”“平”“千/月”这些单位去掉，再写一个函数把“X.X千/月”这种字符串换算成真正的数字。
第四步：异常值过滤。这个阶段可以用简单的统计学方法：比如租金和面积直接过滤掉上下1%的极端值，再结合业务常识——单间租金低于300或高于30000都视为异常；面积低于10平米或高于500平米视为异常。我的经验是过滤规则宁严勿松，因为这直接决定后面Echarts出图的合理性。
3.3 字段规整与衍生变量：价格分析的前提
清洗完基础字段之后，还需要做一些字段规整和衍生变量，这一步是让“大数据分析”真正有分析味道的关键：
- 把价格转为“每平米月租金”：rent_per_sqm = rent / area。这是租房数据分析里最常用的指标之一，能帮你在不同面积段之间横向比较价格；
- 把楼层转为“楼层区间”：低层、中层、高层，用来分析楼层对租金的影响；
- 从发布时间中提取“季度”和“月份”：之后可以做季节租金走势；
- 给户型增加一个“厅室数”的数值列：把“3室2厅”解析成bedrooms=3, livingrooms=2，方便数值分析；
- 把区域字段统一成标准行政区名：比如“朝阳”和“北京朝阳”统一成“朝阳”。
这些衍生变量在Echarts可视化里会变成一个个具体的报表维度。比如用“每平米月租金”做热力图，会比单纯用“总租金”更能反映不同区域的真实租金水平；用“楼层区间”做分组柱状图，能看出高低楼层之间的价差规律；用“月份”做折线趋势图，能讲出“春节后和毕业季租金上涨”的故事。这就是“大数据分析”和“表格展示”的分水岭。
4. Django后端：如何把分析结果变成可调用的接口
4.1 项目初始化与数据持久化设计
Django在这个项目里扮演的角色一定要想明白：它不是一个要给用户注册登录、发布房源的管理后台，而是数据的“中转站”和“服务方”。所以做的时候没必要把Django Admin做得太复杂，重点放在模型设计和数据接口上。
项目初始化的时候，我建议用虚拟环境来装依赖，避免把系统Python环境搞乱。用conda创建虚拟环境后，pip install django pandas mysqlclient（或pymysql），然后把数据库配置改成你的MySQL账号。这里说一个新手高频翻车点：**Django默认用的SQLite对毕设小数据量够用，但一旦你要跑“全国”级别的几十万条数据，SQLite在并发和复杂查询上会很吃力。**我推荐直接用MySQL，在settings.py里配置好连接池，后面做聚合统计的时候能快不少。
数据持久化设计上，我用的是一表到底+冗余字段策略。因为租房数据是扁平结构的，不需要搞太多外键关联。核心表就是HouseInfo，字段包含城市、区域、小区、标题、户型、面积、朝向、楼层、租金、每平米租金、发布时间、链接，再加上一个数据抓取时间。这样做聚合查询的时候直接对单表做GROUP BY就出来了，效率高，逻辑也清晰。
4.2 ORM vs 原始SQL：毕设场景怎么选
写后端接口的时候，很多教程会教你用Django ORM的filter、annotate这些方法。我实际用下来，小数据量场景确实没问题，但当你做类似“按城市统计平均租金、房源量、最高最低价”这种跨行聚合，ORM的写法和原始SQL的易读性差距会显现出来。
我的建议是：**明细查询用ORM，聚合统计用pandas或原始SQL，两者结合分工。**具体做法有两种常见方式，选一种你习惯的就行：
- 方式一：先用Django ORM把需要的数据一次性查出来，转成DataFrame后再用pandas的groupby做分析，最后把分析结果转成JSON返回给前端。这种方式适合你已经在清洗阶段习惯了pandas的写法，逻辑连贯；
- 方式二：把聚合统计写在MySQL视图或者原始SQL查询里，Django用connection.cursor()执行并返回。数据量大、聚合条件复杂的时候效率更高。
我用的是方式一，因为整个项目的分析逻辑已经是pandas风格了，写到后端等于把同一套代码直接复用，不需要再学一套SQL聚合语法。但注意，不要为了方便把所有明细数据一股脑传给前端再在浏览器里算，这样首屏会非常慢，而且答辩时老师一眼就能看出你没有理解“后端分析、前端展示”的分层逻辑。
4.3 接口层设计：前端只管“拿数据”，分析交给后端
接口层是Django的重点，也是你答辩时能拿分的部分。一个清晰的接口设计要遵循一个原则：前端要什么，后端就给什么，前端不要什么，后端绝不多给什么。
我设计的接口大致分成三类：
/api/overview/：返回全国总量统计，包括总房源数、城市数、平均租金、平均面积、最高最低租金等，供首页总览卡片使用；/api/city_rank/?city=北京：返回指定城市的区域排名、户型占比、面积分布、楼层价格对比，供城市详情页使用；/api/trend/?city=上海：返回按月聚合的租金走势和房源量变化，供趋势折线图使用。
每个接口返回的都是按前端Echarts数据结构整理好的JSON，比如地图散点数据就返回[{name: “朝阳区”, value: [经度, 纬度, 平均租金]}, ...]，柱状图就返回{names: [...], values: [...]}。这样做的好处是前端代码极度简化，只需要拿到数据直接setOption即可。
这里有一个很容易忽略的细节：**接口必须做异常兜底。**比如前端传了一个不存在的城市名，后端应该返回一个空的content和合适的status code，而不是直接抛500。我把城市名校验和参数校验都写在接口第一层，写了一个统一的返回格式{code: 200, data: {...}, message: “success”}。这不仅让前后端联调省心，答辩时也能说“我考虑了接口健壮性”。
5. Echarts可视化：把数据讲成人话
5.1 首屏地图：区域分布热力背后的VisualMap配置
Echarts是整个系统最直观的加分项，也是非技术背景的老师最容易看到“工作量”的地方。可视化不是把数据扔进图表就行，核心是选择正确的图表类型来表达你想讲的观点。
首屏我用的是一张全国地图加城市散点，点击某个城市后下钻到该城市的行政区热力地图。这里要注意一个技术细节：Echarts自5.0之后不再内置地图数据，需要单独引入中国地图或城市地图的GeoJSON。如果你用的是echarts 4.x，地图数据是现成的；用5.x就必须额外注册地图，不然图表区域是空白。我的做法是在项目静态目录里放好china.json和各城市的区划json，前端用echarts.registerMap()注册后再setOption。
地图上的VisualMap是热力图的核心配置项，它决定了颜色编码规则。比如你要展示“各区域每平米月租金”，VisualMap的min和max不应该写死，而是根据接口返回的数据动态计算。我习惯设置为数据的最小值和最大值，并把颜色区间设置成由浅到深的渐变，比如浅蓝到深蓝。同时加上tooltip显示该区域的平均租金和房源数量，让用户悬停时能看到具体数字，而不是只能看色块。
5.2 价格分析组合图：多维度指标怎么摆
价格分析页面，我用的是Echarts的组合图，把柱状图和折线图放在同一个x轴上。柱状图放各区域的房源数量，折线图放平均租金，双Y轴分别对应数量和价格。这种组合图的信息量很大，一眼能看到“哪个区域房源多、哪个区域贵”，非常适合城市页面。
配置的时候要注意双Y轴的刻度问题，不然会出现“折线被压扁”或者“柱子矮成一条线”的情况。我的处理方式是：yAxis数组里两条轴，右侧价格轴不强制从0开始，而是用数据的min和max缩放区间，这样折线的起伏才会清晰；左侧数量轴从0开始保持柱子的真实比例。
另外，柱状图上方可以加上label显示具体数值，一旦数据量不大，这个操作能让观感提升很多。交互层面的细节还有Legend点击切换：当页面有多个图表系列，用户点击图例可以隐藏或显示对应系列，这在答辩时操作一下很有演示效果。
5.3 交互细节：Tooltip、Legend动态切换与性能
Echarts的交互配置容易被忽视，但这是“从能显示到好用”的分水岭。我总结三个最值得花时间的点：
Tooltip自定义。默认的tooltip只能显示当前系列的值，我改成自定义formatter，把同一条数据在不同维度下的信息拼在一行里。比如悬停在柱状图某区域时，同时显示“房源量：1234套”、“平均租金：68.5元/㎡/月”，一次hover给全信息。
联动筛选。当统计维度多的时候，我加了一排筛选条件，比如城市、户型、朝向。这些筛选控件和数据量没关系，真正的联动是通过Ajax请求后端接口完成的：用户选完条件后，前端重新请求对应接口，再动态刷新图表。这个应用了“参数变化 -> 重新请求 -> setOption”的核心交互模式，比在Echarts内部写dataZoom要灵活得多。
大数据量渲染性能。租房数据清理完之后规模不小，一个城市可能有上万条记录。如果直接把原始数据全塞给Echarts，页面会卡得不像样。我的做法是前端永远只拿聚合后的数据——后端已经把几十万条明细聚合成了几十个区域的统计结果，图表渲染的节点数很少，天然流畅。如果你做的图确实需要渲染大量散点，可以用Echarts的sampling属性或者使用WebGL渲染模式，但我实测在这个项目场景里不必走到那一步。
6. 联调、部署与答辩：最容易翻车的三个环节
6.1 前后端联调常见问题
前后端联调阶段，最常见的坑就是跨域问题。Django默认不允许跨域请求，如果你用Vue或原生页面单独起开发服务器，前端访问Django接口会直接被浏览器拦截。解决办法很简单：安装django-cors-headers，在settings.py里配置CORS_ALLOWED_ORIGINS。如果你像我一样直接把Echarts页面放在Django的templates静态目录里，那就没有跨域问题，因为同源部署。建议毕设采用后者，省去一个坑。
另一个联调问题是接口字段名不一致。前端拿到的JSON里字段名大小写、命名风格必须前后端统一。我在写接口时定义了统一的命名规范：全部小写下划线，比如city_name、avg_price。前端拿到什么字段就用什么字段，绝不在浏览器端再改一次名字，能减少大量低级踩坑。
6.2 本机演示与服务器部署的差异
很多同学在本地开发一切正常，一到答辩环境就完蛋。这里我建议从第一天就把项目做成“可部署形态”：首先，settings.py里不要硬编码本地数据库地址和密码，用环境变量管理；其次，静态文件用Django的static配置统一收集；第三，不要把爬虫写进Web请求里——答辩时的网络环境不可控，爬虫脚本应该作为独立模块预先执行，数据入库后Web系统只负责读取。
如果答辩需要现场演示，强烈建议提前准备一个演示数据备份，并确保在没有外网的环境下也能完整运行。我当时的做法是：先把所有城市的清洗结果数据导出成JSON文件放进项目里，万一数据库连不上，前端也能加载本地JSON兜底展示。这个“降级方案”在答辩时非常实用。
6.3 答辩被问概率最高的几个技术点
根据我带过的经验，答辩老师对这类项目的提问非常集中在几个点上，提前准备好答复，现场就会游刃有余：
问：你爬虫的合法性如何保证？答：我这里只抓取了各平台公开可访问的页面数据，不涉及用户隐私；请求频率设置了间隔，避免对服务器造成压力；并且在演示前已提前完成抓取，现场不依赖实时抓取；采集用途仅限学习和科研。
问：爬虫被封了怎么办？答：我会分三步解决，先检查是单IP频率过高还是请求头特征明显，再调整请求间隔并随机化UA，最后如果仍然不行才考虑用代理服务，但毕设阶段一般第一二步就够了。
问：数据清洗和分析的逻辑是什么？答：我会从数据质量三要素来讲，完整性、准确性、一致性，然后分别对应缺失值处理、异常值过滤、格式统一，最后展示清洗前后的数据对比和可视化结果差异。
问：为什么用Django而不用Flask？答：综合来看，Django自带Admin、ORM、认证体系，适合需要持久化和复杂数据管理的场景，同时项目结构规范，便于后续扩展；但实际选型也要看个人熟悉程度，用Flask或FastAPI做同样的事也完全可行，关键是链路完整。
问：Echarts的数据是从接口实时查询还是提前算好？答：我是先通过pandas离线完成清洗和聚合分析，再把聚合结果保存到MySQL，Web端请求接口时通过Django ORM查询这些聚合结果，不涉及大量明细数据的实时计算，所以接口响应快，架构上也更清晰。
这些回答不要太长，控制在“结论 + 一句依据 + 一句细节”的结构里，就能让老师觉得你是真做过，而不是背的。
最后说点我在做完整个项目之后的体会：这类“爬虫+大数据+Django+Echarts”的选题，本质是考察你把数据从无到有、从脏到净、从数字到图表走完一整套链路的能力。**它最迷人的地方不是某个单一技术点有多深，而是每个环节都逼着你用“下一个环节的需求”来重新审视自己当前的做法。**做的时候别急着追求炫酷效果，先把数据弄干净、接口调通、图表能跑，再想着加动画和大屏。整个链路跑通的瞬间，你就已经离“毕设稳了”非常近了。
