提起“计算机毕业设计”很多人的第一反应都是头大。倒不是因为题目难而是既要写代码又要写文档还得保证系统能跑、能演示、能答辩整个流程环环相扣。我这两年陆陆续续帮人看过不少类似题目发现“Python Django Requests爬虫 数据分析 可视化”这一套组合拳出现在租房、二手房、招聘、电商等各类选题里的频率特别高。仔细想想也合理这套技术栈足够经典爬虫负责拿数据、Django负责把数据变成Web系统、再借可视化图表把分析结果讲清楚一条链路完整既能体现工程量又方便在答辩时演示亮点。这篇就借着“Python 58同城租房数据分析系统”这个标题把整个项目从零到一的完整思路、核心代码逻辑、实操过程以及那些我在验代码时踩过的坑一次性讲清楚。这篇文章不是让你无脑复制粘贴而是希望你理解每块代码为什么这么写、每个模块之间怎么串联最后能照着做出一套自己的系统哪怕题目换成“二手房分析系统”或者“招聘数据分析系统”也能改得动、说得清。1. 项目整体拆解这套租房数据分析系统到底在做什么1.1 核心业务逻辑从“数据采集”到“数据展示”的完整闭环先把这个项目要解决的需求理清楚。58同城上的租房信息量很大但信息是零散地分布在列表页和详情页里的今天一个价、明天一个价东城区什么价位、朝阳区什么户型全靠肉眼去翻去记根本没有效率。这个系统的核心价值就是自动抓取租房房源数据存到本地数据库再通过Web页面把统计结果用图表展示出来让人一眼看清“租在哪、租多大、花多少钱”。所以整个项目可以拆成三个核心环节数据采集Requests爬虫、数据存储与业务处理Django模型与视图、数据可视化呈现图表库渲染。如果你对毕业设计的套路熟悉会发现这个结构非常“标准”——它既覆盖了计算机专业必修的网络请求、Web框架、数据库知识又因为这个数据是真实抓下来的比起虚构数据做的管理系统演示效果要好得多。1.2 技术选型为什么偏偏是Django Requests ECharts这套组合我把选型逻辑说明白答辩时老师问“为什么选这些技术”你也能答得有理有据。先说爬虫这块。Python里做爬虫主流无非是Requests、Scrapy、Selenium三选一。Scrapy是框架级选手功能强大但学习曲线陡而且对小型项目来说有点“杀鸡用牛刀”Selenium能渲染JavaScript对付动态页面很强势但启动浏览器实例的代价是运行慢、内存吃紧。而Requests作为HTTP请求库轻量、直接、可控性强适合目标页面数据是服务端渲染的场景。58同城的租房列表页之前是可以在HTML里直接拿到房源基础信息的用Requests就能搞定配合解析库提取数据性价比和可控性都最好。再说后端框架。Python后端绕不开Django和Flask两个选择。Flask轻巧灵活项目结构全凭自己组织适合微型应用Django则是“全家桶”风格自带ORM、Admin后台、模板系统、表单处理对毕业设计这种需要“麻雀虽小五脏俱全”的场景非常合适。Django的ORM能让我直接操作模型类而不是写SQL迁移、建表、数据操作都自动化省下的时间可以花在爬虫和可视化上面。最后说可视化这一层。图表展示的后端方案有两条路一是用Pyecharts在Python后端生成HTML或者图片二是用JavaScript图表库最典型就是ECharts在前端页面渲染。我推荐后者原因很直接Django的模板系统对前端资源支持很好ECharts的交互效果、缩放、联动都比静态图片强太多而且只需要给前端页面输出JSON格式的统计数据就行逻辑上后端只关心“统计结果长什么样”不关心“图表画的怎么样”职责清晰。1.3 项目目录结构与数据流向先看清全局再动手写代码一个靠谱的Django项目目录结构从一开始就要理顺。别小看这一步我见过太多人代码全往一个文件里怼最后越改越乱、越写越崩溃。这个租房分析系统的目录规划如下rent_analysis/ ├── manage.py ├── requirements.txt ├── db.sqlite3 ├── spider/ │ ├── __init__.py │ ├── scraper.py # 爬虫核心抓取与解析 │ └── config.py # 爬虫配置UA、URL模板、字段映射 ├── rentapp/ │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ ├── models.py # 房源数据模型 │ ├── views.py # 页面渲染与统计接口 │ ├── admin.py │ └── migrations/ └── templates/ ├── index.html ├── charts/ └── ...数据流向也很直白爬虫模块从58同城租房列表页抓取原始HTML → 用解析库提取字段 → 存入SQLite数据库 → Django视图层查询数据库并做聚合统计 → 把结果以JSON格式返回模板页面 → ECharts接收JSON数据渲染图表。整条链路单向流动每个环节只做一件事出了问题查起来也快。注意抓取任何网站的数据前务必先查看该网站的 robots.txt 协议并确认你的行为仅限于个人学习用途。爬虫程序要设置合理的请求间隔不要给目标服务器造成压力。这是工程伦理问题也是毕业设计开题时老师一定会问的问题。1.4 功能模块地图做个让自己答辩时有底气的功能清单很多同学做毕业设计容易犯一个毛病就是功能看着很多实际上全是空架子。我这个系统的功能设计思路是“少而精每个都能演示”房源数据管理、区域分布统计、租金价格区间分析、户型占比统计、可视化大屏展示这五个核心模块足够撑起一场答辩演示。区域分布统计解决的是“哪个区域的房源最多”这个问题用柱状图呈现租金价格区间分析解决的是“某个区域一个月租金大概什么水平”这个问题用饼图或者直方图呈现户型占比统计聚焦的是“一居、两居、三居各占多少比例”同样用饼图呈现。最后在首页搭一个数据总览面板把房源总数、平均租金、最高租金、最新抓取时间等关键指标用数字卡片或者大屏形式摆出来一打开就是满满的“数据看板”既视感。2. 环境准备与项目初始化先把地基打牢2.1 Python虚拟环境与Django安装每一步都别想当然我建议所有做Python Web项目的同学第一步永远是创建虚拟环境没有例外。很多项目跑不起来或者依赖冲突十有八九是全局环境里一堆包混在一起。操作命令如下# 创建虚拟环境 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS/Linux source venv/bin/activate # 升级pip避免装包时出现奇怪问题 python -m pip install --upgrade pip # 安装核心依赖 pip install django requests beautifulsoup4 lxmlDjango版本这里多说一句。新版本的Django比如4.x、5.x对Python版本有要求装之前先确认自己Python的版本。如果你是Python 3.10及以上直接装最新Django没什么问题如果是Python 3.8或者3.9建议用Django 3.2或者4.0这个区间否则可能碰到版本兼容性问题。这个坑我在帮人调试环境时遇到过太多次了装了半天依赖跑不起来最后发现是版本不匹配。装好之后创建一个Django项目和一个应用# 创建项目名字用rent_analysis django-admin startproject rent_analysis # 进入项目目录 cd rent_analysis # 创建应用名字用rentapp表示租房应用 python manage.py startapp rentapp创建完应用后一定要去settings.py的INSTALLED_APPS里把rentapp加进去否则后面执行数据库迁移时系统根本不会认识你这个应用的模型。2.2 数据库模型设计房源数据怎么存才能方便后续统计模型设计是整个系统数据层面的基石。我见过有人偷懒把所有字段塞进一个JSON字符串里存看着省事真到了要按区域分组统计的时候就傻眼了。合理的做法是用关系型字段把每个维度独立出来便于后续ORM聚合查询。对于租房信息核心字段至少包括房源标题、小区名称、所在区域、户型几室几厅、面积平方米、月租金元、租赁方式整租/合租、朝向、楼层、发布日期、房源详情页链接。其中区域、租金、户型这三个字段后面要作为分析维度索引要设好。# rentapp/models.py from django.db import models class House(models.Model): title models.CharField(max_length200, verbose_name房源标题) community models.CharField(max_length100, verbose_name小区名称, nullTrue, blankTrue) district models.CharField(max_length50, db_indexTrue, verbose_name所在区域) layout models.CharField(max_length50, verbose_name户型) area models.FloatField(verbose_name面积(㎡), nullTrue, blankTrue) rent models.IntegerField(db_indexTrue, verbose_name月租金(元)) rent_type models.CharField(max_length20, verbose_name租赁方式, nullTrue, blankTrue) orientation models.CharField(max_length20, verbose_name朝向, nullTrue, blankTrue) url models.URLField(uniqueTrue, verbose_name房源链接) class Meta: db_table house_info verbose_name 租房房源信息 def __str__(self): return self.title设置uniqueTrue的URL字段是个关键操作。爬虫过程中同一个房源页面可能被重复抓取如果每次都直接入库数据表里就会产生大量重复记录后续统计的数据就彻底失真了。Django的ORM写入时可以先get_or_create或者用update_or_create这样既保证数据是新的又不会重复插入。2.3 数据库迁移与超级用户两个很容易被忽略的必做动作模型写完之后执行迁移python manage.py makemigrations rentapp python manage.py migrate这一步会生成迁移文件并在数据库里创建house_info表。做完之后我建议顺手创建一个超级用户python manage.py createsuperuser创建超级用户不是为了走个过场而是因为Django的Admin后台搭建起来后你可以直接在Web页面上手动添加、修改、删除房源数据。这在爬虫数据不理想或者需要人工修复数据时非常有用。而且把Django管理后台截图放进毕业设计文档里也是一个不错的展示点。到这里项目的骨架已经立起来了。接下来的核心任务是把爬虫这块硬骨头啃下来。3. Requests爬虫模块的实现从页面到结构化数据的完整拆解3.1 反爬应对策略先把自己变成一个“正常访客”爬虫这部分的细节直接决定你能不能拿到干净的数据。58同城这种大平台做了不少反爬手段最常见的就是检查User-Agent浏览器标识、请求频率、Cookie有效性等。所以爬虫代码的第一件事就是把自己伪装成一个真实用户的浏览器。我的做法是先在浏览器里随便打开一个58同城租房页面按F12打开开发者工具在“网络”标签里随便点一个请求复制出请求头信息重点是User-Agent和Cookie这两个字段。然后用Requests的Session对象发起请求这样可以让请求在同一个会话里保持状态# spider/config.py 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, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, Connection: keep-alive, } # spider/scraper.py import requests def get_page(url): session requests.Session() session.headers.update(HEADERS) try: resp session.get(url, timeout10) resp.encoding utf-8 # 确保页面按UTF-8解码避免中文乱码 if resp.status_code 200: return resp.text else: print(f请求失败状态码: {resp.status_code}) return None except requests.RequestException as e: print(f请求异常: {e}) return Noneresp.encoding utf-8这一步很多人会漏。Requests库在不指定编码时会根据HTTP响应头猜测编码方式有时候猜得不对拿到的text就是一坨乱码。同时请求间隔要留够页面里每一页抓取之间建议加0.5到1秒的随机延迟别把对方服务器当自家内网打。3.2 HTML解析与字段提取用lxml还是正则拿到HTML之后接下来就是从一堆标签里精准剥离出房源信息。Python解析HTML的主流选项是BeautifulSoup lxml解析器或者直接用lxml的xpath。我个人经验是列表页结构相对规整时用xpath的效率更高页面结构不规整、有很多嵌套时BeautifulSoup的容错性更好。大部分时候我直接用BeautifulSoup写起来更顺手因为它的API对新手友好代码可读性也强答辩时老师问起来解释起来也轻松。58同城早期的租房列表页里一个房源项大致对应一个li标签标题、小区名、租金等信息分布在对应的类名节点里。解析逻辑是这样from bs4 import BeautifulSoup def parse_list_html(html): soup BeautifulSoup(html, lxml) items [] # 每个房源块的容器节点视页面实际结构调整选择器 for div in soup.select(.list-item): try: title_tag div.select_one(.item-title a) or div.select_one(.des a) title title_tag.get_text(stripTrue) if title_tag else rent_tag div.select_one(.item-price .price) or div.select_one(.price span) rent int(rent_tag.get_text(stripTrue).replace(元/月, )) if rent_tag else 0 district_tag div.select_one(.item-zone) or div.select_one(.where) district district_tag.get_text(stripTrue).split(/)[0] if district_tag else community_tag div.select_one(.item-zone .infor) or div.select_one(.where .infor) community community_tag.get_text(stripTrue) if community_tag else layout_tag div.select_one(.item-desc) or div.select_one(.des) layout layout_tag.get_text(stripTrue) if layout_tag else url_tag div.select_one(a) url url_tag.get(href, ) if url_tag else if not url.startswith(http): url https://zz.58.com url items.append({ title: title, community: community, district: district, layout: layout, rent: rent, url: url, }) except Exception as e: # 单条数据异常不阻断全页解析 continue return items这里有个很重要的工程思维单条数据解析出错时不能直接让整个程序崩溃。列表页上偶尔会混入几条广告推荐或者某个房源信息字段缺失这种情况用try...except跳过去继续解析下一条。这是专业化爬虫和玩具脚本的关键区别。3.3 多页抓取与请求频率控制别把“爬虫”写成“轰炸机”58同城的租房列表通常是分页的URL上带着页面参数比如pn1、pn2。多页抓取的逻辑很直接构造URL列表、逐页请求、逐页解析、统一入库。但我强烈建议在循环里加两个东西随机延迟和随机UA切换。随机延迟用time.sleep()就能实现间隔设在0.5到1.5秒之间比较稳妥。随机UA切换则可以用fake_useragent这个库每次请求换一个浏览器标识进一步降低被识别为同一请求头的概率。如果你的目标是抓几百条数据做样本分析这两个措施足够用了如果非要追求几万条的规模那需要更高级的代理池方案但对毕业设计来说完全没必要。import time import random def crawl(url_template, total_pages10): for page in range(1, total_pages 1): url url_template.format(pagepage) html get_page(url) if html: items parse_list_html(html) save_items_to_db(items) print(f第{page}页完成解析到{len(items)}条房源) else: print(f第{page}页解析失败等待重试...) time.sleep(random.uniform(0.5, 1.5))抓取结果最终入库时用update_or_create按URL去重from rentapp.models import House def save_items_to_db(items): for item in items: House.objects.update_or_create( urlitem[url], defaults{ title: item[title], community: item.get(community), district: item.get(district), layout: item.get(layout), rent: item.get(rent, 0), rent_type: item.get(rent_type), } )说实话爬虫这部分想讲透能写好几篇长文。对这套系统来说上面的代码已经够支撑一个能演示、能统计、能讲逻辑的数据基础了。4. 数据分析与可视化让数据从“能看”到“能说话”4.1 统计口径设计先想清楚“要展示什么”再写代码数据抓下来、存进数据库只是第一步。租房数据分析系统最核心的价值在于它能在Web页面上告诉用户和评委这个区域的市场到底是什么样。在做可视化之前我通常先列一个统计需求清单明确自己需要哪些分析维度。我这套系统的统计口径是这么定的出租房源总量体现数据规模、区域房源分布TOP10柱状图展示集中度、租金价格区间分布直方图或者饼图展示价格带、户型占比饼图展示一居两居三居比例、平均租金与最高租金数字卡片展示核心指标。这些维度覆盖了“地点、价格、户型、总体情况”四个角度足以支撑起一份像样的市场分析演示。4.2 Django视图层聚合查询ORM分组统计的精髓统计逻辑放在Django视图层用ORM的聚合函数完成。以“按区域统计房源数量”为例from django.db.models import Count, Avg, Max def get_district_stats(): stats ( House.objects.values(district) .annotate(totalCount(id), avg_rentAvg(rent)) .order_by(-total)[:10] ) return list(stats)这段代码翻译成SQL就是SELECT district, COUNT(id) as total, AVG(rent) as avg_rent FROM house_info GROUP BY district ORDER BY total DESC LIMIT 10;。Django的ORM把复杂的分组聚合封装得明明白白这就是我前面说的选Django的底气所在。租金价格区间统计则稍微复杂一点因为“价格区间”不是数据库里的字段需要在Python里手动分桶。比如把租金划分为“1000元以下、1000-2000元、2000-3000元、3000-5000元、5000元以上”几个桶插入桶和计算每个桶的房源数量def get_rent_bins(): bins {1000以下: 0, 1000-2000: 0, 2000-3000: 0, 3000-5000: 0, 5000以上: 0} for rent in House.objects.values_list(rent, flatTrue): if rent 1000: bins[1000以下] 1 elif rent 2000: bins[1000-2000] 1 elif rent 3000: bins[2000-3000] 1 elif rent 5000: bins[3000-5000] 1 else: bins[5000以上] 1 return bins这个逻辑不复杂但它是数据分析的典型操作把连续值离散化可视化呈现才能直观。单价分析、价格中位数、面积与租金的关系这些指标其实都是从这套思路上延伸出来的可以根据手里的数据量灵活扩展。4.3 ECharts前端渲染JSON数据如何变成图表后端统计完成之后把数据通过Django的JSONResponse接口输出前端页面用ECharts读取并渲染。我建议专门做一个统计接口视图这样图表需要的JSON数据可以按需请求不用整个页面一起刷新。# rentapp/views.py import json from django.http import JsonResponse from django.shortcuts import render def dashboard(request): return render(request, index.html) def district_stats_api(request): data get_district_stats() payload { categories: [item[district] for item in data], values: [item[total] for item in data], avg_rents: [round(item[avg_rent]) for item in data], } return JsonResponse(payload)前端页面就非常简单干净了一个div容器放图表一段JavaScript发请求、拿数据、渲染ECharts// templates/index.html 中部分代码 fetch(/api/district-stats) .then(response response.json()) .then(data { const chart echarts.init(document.getElementById(districtChart)); chart.setOption({ title: { text: 区域房源分布TOP10 }, tooltip: {}, xAxis: { data: data.categories }, yAxis: {}, series: [{ type: bar, data: data.values, itemStyle: { color: #5470c6 } }] }); });这种前后端分离思路虽然是用Django模板渲染的页面但数据获取已经是接口化操作了。答辩时你可以强调“这个系统采用前后端解耦的数据交互方式”这可是加分项。4.4 可视化大屏布局技巧不是所有图表堆一起就好看最后聊一点关于“好看”的经验。很多毕业设计的可视化页面一眼看去就是几个图表毫无章法地堆在一起显得特别业余。我的建议是首页不要贪多重点做一屏信息最上面一排放3个数字卡片房源总数、平均月租金、统计区域数量中间左侧放区域分布柱状图中间右侧放租金区间饼图下面放户型占比图。这样的布局信息层级清晰屏幕不用滚动就能看完演示效果最好。配色上如果没有设计功底就老老实实用最经典的深色背景配蓝绿色系数据点或者白底配蓝红对比。不要一个图表一个颜色整体会显得非常乱。ECharts默认主题其实就不错稍微调整透明度、加一点渐变就够毕业答辩的档次了。5. 系统联调与部署把代码跑起来的完整流程5.1 爬虫接入Django ORM的两种姿势爬虫和Django项目联调时有一个常见的设计问题爬虫脚本是独立运行还是集成到Django命令体系里我强烈推荐集成进去用Django的自定义管理命令启动爬虫。这样做的好处是爬虫自动加载Django的配置和模型不需要操心数据库连接问题还能用Django的日志系统记录运行情况。在rentapp应用下创建management/commands/crawl_house.py# rentapp/management/commands/crawl_house.py from django.core.management.base import BaseCommand from spider.scraper import crawl class Command(BaseCommand): help 抓取58同城租房数据 def add_arguments(self, parser): parser.add_argument(--pages, typeint, default10, help抓取页数) def handle(self, *args, **options): pages options[pages] self.stdout.write(f开始抓取房源数据共{pages}页...) crawl(https://.../zufang/pn{}/, total_pagespages) self.stdout.write(self.style.SUCCESS(抓取完成))然后一行命令就能启动python manage.py crawl_house --pages 10这个做法的好处在于你把爬虫纳入了Django的项目管理体系中答辩时展示代码结构逻辑非常清晰评审老师顺着manage.py的命令就能看懂你的项目入口印象分会高不少。5.2 路由配置与页面渲染让所有模块串成一条线接下来要把URL路由、页面视图、模板串起来。在rentapp/urls.py里配置路由并在项目根路由rent_analysis/urls.py里include进去# rentapp/urls.py from django.urls import path from . import views urlpatterns [ path(, views.dashboard, namedashboard), path(api/district-stats, views.district_stats_api, namedistrict_stats_api), path(api/rent-bins, views.rent_bins_api, namerent_bins_api), path(api/layout-stats, views.layout_stats_api, namelayout_stats_api), ]然后启动开发服务器python manage.py runserver浏览器访问http://127.0.0.1:8000就能看到首页大屏和数据图表了。5.3 把真实页面效果跑出来的顺序建议整个系统第一次完整跑通的顺序我建议严格按照“迁移数据库 → 采集数据 → 启动服务 → 查看图表”来操作。先确认表能建、数据能存再谈前端看板。很多同学喜欢先把页面做漂亮最后再抓数据结果前端调试了半天总是空数据也不知道是接口问题还是数据没入库排查起来非常费劲。数据入库后强烈建议先在Django Admin后台看一圈数据长什么样确认字段没存错、租金没存成字符串、区域没有一半空白。数据质量过关了再去看图表这时候如果图表不对那基本就是统计逻辑的问题问题定位范围就小多了。我见过太多人上来直接改前端折腾半天最后发现是数据源就是脏的白白浪费一下午。6. 运行中的常见问题与避坑指南6.1 爬虫抓不到数据的常见原因我调试这套系统时最常遇到的问题就是爬虫什么都抓不到。排优先级的话先看请求是否成功——在代码里打印resp.status_code如果返回403或者302基本就是被反爬拦截了。对策是确认UA和Cookie是否合理、请求间隔是否太短。再看解析逻辑是否跟上了页面结构调整——58这种大站改版频率不低上线前刚写好的选择器可能第二天就失效了。这种情况的排查方式很简单把页面HTML保存到本地写个单独脚本调试选择器改到能正确提取为止再重新整跑爬虫。6.2 Django迁移和静态文件加载问题前后端联调时的第一号必踩坑是静态文件404。ECharts的JS文件如果放在static目录下你必须先在settings.py里确认STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]模板里引入时也要注意{% load static %} script src{% static js/echarts.min.js %}/script别直接把script src/static/js/echarts.min.js写死Django模板语法只能通过{% static %}来正确处理静态文件路径。另一个高频问题是makemigrations之后忘了migrate导致运行时报“表不存在”的OperationalError这种情况执行一次迁移就好不是代码问题。6.3 数据入库杂音的清洗策略真实爬虫抓下来的数据不可能像手工录入那么干净。“2000元/月”这种带单位的字段、面积有时候是“80㎡”、有时候是“80平米”、甚至还有“暂无数据”这些情况必须处理。我的处理方式是写一个专门的数据清洗函数在入库前统一处理租金字段只保留纯数字面积字段统一替换中文单位符号区域字段碰到null或空字符串就填“未知”。def clean_rent_text(text): # 只提取文本中的数字部分 import re match re.search(r\d, text or ) return int(match.group()) if match else 0这个清洗函数看着简单但它决定了你的统计结果是不是能看的。不夸张地说数据清洗占整个爬虫工作量的三成以上别嫌它繁琐这一步偷懒后面所有图表都是错的。6.4 数据库选型权衡这个项目我默认用的是Django自带的SQLite轻量、零配置、对几千条数据量完全够用。但如果你打算在毕业设计文档里写“使用MySQL数据库”那就得在settings.py里改数据库配置本地安装好MySQL并修改DATABASES配置。如果数据量并不大我建议你诚实一点用SQLite就够了理由充分零部署成本、文件型数据库适合原型系统演示。答辩时你更需要在意的是“为什么这个量级的数据用这个库完全合理”而不是盲目追求重型数据库。7. 答辩现场与项目优化的加分细节7.1 演示时的节奏设计最后说点真正能让你在答辩时稳住场子的经验。打开系统首页后不要急着指着图表讲。第一件事是给老师看“数据规模”——通过Admin后台或者数据库里展示抓取到的房源条数证明这些分析不是用假数据生成的而是真实从网上采集的。然后点开爬虫脚本的代码指着请求间隔、UA伪装、异常处理三个点讲清楚自己的爬虫是怎么规避反爬的。再切回首页逐个展示图表讲清楚每个图表的统计口径和业务含义。最后一定要留一个“可扩展”的口子比如“目前只分析了列表页信息后续还可以对房源详情页做词频分析挖掘小区周边配套信息”这句话能让老师觉得你有继续研究的能力。7.2 代码规范与算法优化方向项目代码本身不建议你把所有逻辑都堆在views.py里。爬虫归spider模块管、模型归models.py管、统计逻辑单独拆一个analysis.py出来页面视图只负责调度。模块职责分清楚之后不仅是代码可维护性的问题更是你答辩讲代码结构时的加分点。“我这个系统是用三层职责分离的思想组织的”这句话的分量比你想象的更重。算法层面如果想让项目在数据量大的场景下表现更亮眼可以在查询统计时用cache_page做页面级缓存给统计接口加上Django的缓存机制避免每次刷新页面都重新计算一遍全库聚合。这个话题在答辩里能跟高并发优化扯上关系虽然只是入门级的优化但绝对足够证明你认真考虑过可用性问题。8. 写在最后的经验之谈这个选题做下来我最深的感触是毕业设计的难点从来不在某一个技术单点而在把爬虫、数据库、后端、前端这四样东西串成一个整体。很多人写爬虫的时候行云流水一到接入Django就卡壳也有人前端图表调得挺好看结果数据源一换就全盘崩掉。真正花时间的地方其实是数据格式的统一、模块之间接口的约定、异常情况的兜底。我建议你上手的时候先别急着把每个部分做到完美而是先把一条最简链路跑通手动往数据库里塞10条假数据让Django跑起来、图表画出来再回过头写爬虫补数据。这个思路能让你从第一天起就看到完整系统的样子后面每一步都是加速而不是推翻重来。做这套系统的过程中多留点心多敲几行注释、多想想为什么这么设计半年后回看你会发现这个毕业设计至少让你把Python Web的核心套路吃得透透的。这些能力才是比一个“通过”的答辩成绩更值钱的东西。