每年到毕业季，计算机专业的同学被问到最多的一个问题就是：毕设做什么？做管理系统太水，做算法研究又怕搞不定。如果你正好关注考研、数据分析、前后端分离这些方向，那“考研分数线预测+院校推荐”这个题目几乎是个完美答案。这套系统用Django提供后端接口、Vue.js渲染前端页面，再配合ECharts做可视化，既能展示你懂业务、会建模、能工程落地的综合能力，又有非常清晰的大数据应用场景。这篇内容我把整个系统的拆解思路、核心模块实现、算法落地的细节、以及我实际开发中踩过的坑全部写出来，给准备做类似题目的同学一个可以直接参考的路线。
这个项目的时间跨度从数据准备、模型训练到前后端联调，我个人完整做下来大概需要六到八周，适合有一定Python基础、想认真把毕设做成“能演示、能答辩、敢上线”的同学。文中涉及的所有技术点，我都会以“为什么这么做”的视角来解释，代码和表结构也会给到可直接复用的程度。
1. 整体设计思路：为什么选 Django + Vue.js 这套组合
1.1 选题价值：分数线预测与院校推荐为什么适合做毕设
先聊聊选题。很多同学的毕设选题要么太“大而空”，比如“基于大数据的智慧校园平台”，听起来唬人，实际做起来就是CRUD加几个图表；要么太“偏门”，比如纯研究某个改进算法，工作量集中在论文里，系统演示环节非常单薄。考研分数线预测与院校推荐这个题目好就好在它把业务、数据、算法、系统四件事全占了。
从业务角度，考研是每年几百万人的刚需场景，分数线预测和院校推荐有真实的用户痛点和清晰的交互逻辑，评委老师一听就能理解。从数据角度，考研数据天然是结构化的：院校代码、专业代码、历年复试分数线、录取人数、报录比、国家线趋势，这些都很容易获取和整理，也方便做清洗、补全、统计分析。从算法角度，分数线预测可以落在时间序列和回归模型上，院校推荐可以落在协同过滤和规则匹配上，难度适中，不会因为算法太深而失控。从工程角度，Django提供完整的ORM、Admin后台、DRF接口层，Vue.js配合ElementUI能快速搭出漂亮的管理界面，两个技术栈都是当前企业级开发的主流，写在简历里也不掉价。
另外，这类系统有一个隐藏优势：它天然具备“可解释性”。评委问“你预测出来的分数线为什么可信”，你可以把历史趋势、增长幅度、同类院校对比这些证据链展示出来；问“推荐结果怎么来的”，你可以把匹配规则明明白白列出来。这种能讲清楚为什么的能力，在答辩环节非常加分。
1.2 架构选型：前后端分离的底气在哪里
再说技术选型。Django + Vue.js 的组合在今天已经是毕业设计里的“标配顶配”了。Django在Python生态里是最成熟的重量级框架，自带Admin后台、Auth认证、ORM、中间件机制，你不用额外拼装太多组件就能把服务端逻辑撑起来；Vue.js则胜在渐进式、上手曲线平滑、组件化开发体验好，配合ElementUI做后台管理界面，几天就能出活。
更关键的是，前后端分离这种架构本身就是一个很好的答辩话题。Django端只负责提供RESTful API，用DRF（Django REST Framework）写序列化器和视图集；Vue端通过axios调用接口渲染页面。两个服务独立部署、独立开发，数据通过JSON交换。这样做的好处一是分工清晰，前端只管展示和交互，后端只管数据和业务；二是扩展方便，以后加小程序端或者App端，只要复用同一套API就行；三是能体现你对现代Web开发模式的理解，而不是像传统模板渲染那样把HTML和Python揉在一起。
在实际开发中，我会给同学们一个建议：如果基础偏弱，可以先做单体版本，也就是Django的Template渲染Vue的CDN版本，整体跑通后再拆成正式的前后端分离。我在文末的常见问题里会具体说怎么做这一步过渡。
1.3 大数据元素的落地：不堆概念，用数据说话
很多同学一听“大数据毕业设计”，第一反应就是要去搭Hadoop、Spark集群，其实这是误区。对本科毕设来说，“大数据”的核心体现应该是数据的规模、处理的思路和可视化的效果，而不是工具链的复杂度。用Django从公开渠道采集近十年三百多所院校的招生数据、复试分数线、录取统计，这本身就是一个百万级数据量的数据集，足以支撑你做清洗、分析、可视化。
我在这个系统里保留了两个“大数据处理”的关键环节。一是数据清洗：原始数据里同一所院校在不同年份的院校代码可能不一致，专业名称写法也可能有差异，比如“计算机技术”和“计算机科学与技术”在部分年份的表格里会被混用，这些需要用规则加人工校验的方式做归一化。二是数据分析：在预测模块里，我不仅看单条数据，还会做横向对比，比如同类地区、同层次院校的分数变化趋势，再用聚类思路把院校划分成“热门稳定型”“逐年上升型”“波动较大型”等类别，这些分类结果反过来会作为推荐系统的输入特征。这两个环节写进论文里，比单纯写“用了大数据技术”有说服力得多。
2. 核心功能模块拆解：预测和推荐这两台引擎
2.1 分数线预测模块：时间序列与回归的取舍
分数线预测是这个系统的技术核心。分数线在时间维度上有明显的趋势性，比如计算机专业近十年整体上涨、部分院校在特定年份出现大幅波动。处理这类数据最经典的方法是时间序列模型，比如ARIMA、指数平滑，也可以用机器学习里的回归模型做特征工程。
我在实现时采用的是“双轨制”：第一轨用指数平滑的Holt线性趋势模型拟合历年分数线，给出下一年的预测值和置信区间；第二轨提取特征，包括院校层次、省份、学科热度、近三年涨幅、当年国家线变化趋势，使用线性回归或GradientBoosting做多因子预测。最终结果不是简单取平均，而是根据预测年份距离数据末尾的远近做加权。
比较重要的一点是，很多同学在预测时容易踩这个坑：直接用全部年份的数据训练，没有做时间序列的样本切分。正确的做法是按时间顺序切分，比如用前七年训练、后三年验证，不能用随机切分，否则会造成数据泄露，验证指标虚高。我在系统里专门写了一个评估方法，展示近三年预测值与实际值的对比误差，并把每个院校每个专业的预测误差存在数据库里，前端用表格和图表展示。这部分内容是答辩时最能体现你懂行的细节。
预测结果最终会落到一张prediction_result表，字段包括院校、专业、年份、预测值、置信区间、常用特征值、模型类型。前端预测页面上会展示一条时间轴折线图，把历史真实值、预测值、置信带全部画出来，用户一眼就能看出趋势。
2.2 院校推荐模块：协同过滤与规则匹配的取舍
院校推荐的数据基础是用户填写的意向表单：目标省份、目标城市等级、专业方向、本科院校层次、预估分数、是否接受B区调剂、学费预算等。推荐策略我分了四层，逐层筛选，最后生成推荐列表。
第一层是硬性条件过滤，比如省份、专业方向、学硕还是专硕，这些条件不满足的直接排除。第二层是分数匹配，根据用户预估分数与目标院校近三年分数线做区间匹配，划分冲刺、稳妥、保底三档。这里有一个细节非常关键：不能只看一年分数线，要看三年趋势。比如某校某专业去年分数突然从350涨到370，如果只看一年的数据，很多分数在360左右的同学就被错误地划到“冲刺档”，实际上该校往年长期在350左右，今年可能是小年，明年回落的概率较大。我的实现里会对三年分数做加权平均，权重按时间衰减。第三层是热度匹配，用报考人数、录取人数、报录比计算热度指数，给用户展示竞争激烈程度。第四层是协同过滤，如果历史用户中有和你画像相似且成功上岸的人，系统会把他们的最终选择院校作为强推荐。
协同过滤部分我用的是基于用户的协同过滤算法，相似度计算采用余弦相似度。用户特征的构造方式是：把表单选项转为向量，比如省份编码、专业编码、分数归一化、城市等级编码，拼成一个特征向量。这一层在论文和技术答辩里都是亮点，而且实现难度可控，用Python字典结构和NumPy就能跑，不需要引入额外的推荐框架。
2.3 数据模型设计：核心表结构和关系
数据库表的设计会直接影响后面所有代码的复杂度，我这里给出一个经过实践调整的核心表设计，供直接参考。
用户表auth_user使用Django自带的用户表扩展，通过OneToOne扩展出profile字段，存本科院校、目标专业、意向省份等。
院校表school的字段有：name（院校名称）、code（院校代码）、province（省份）、city（城市）、level（985/211/双一流/普通本科）、is_34（是否34所自划线）、tags（标签，如理工类、师范类）、latitude和longitude（用于地图可视化）。
专业表major的字段有：name、category_code（学科门类）、degree_type（学硕/专硕）、exam_subjects（考试科目）。
分数线表score_line是最核心的表，字段包括：school（外键）、major（外键）、year、total_score（复试分数线总分）、political_score、english_score、math_score、professional_score（专业课线）、enroll_count（录取人数）、apply_count（报考人数）、source_type（数据来源）。这张表上要建联合索引(school, major, year)，因为所有的查询都是基于这个组合。
推荐记录表recommend_record保存每个用户的推荐结果，字段包含：user、school、major、type（冲刺/稳妥/保底）、reason（推荐理由，JSON格式，存匹配依据）、created_at。
这样一套表结构，既保证了预测模块和推荐模块的数据需求，又不会因为过度设计导致后期维护困难。需要提醒的是，外键关系不要建得太深，三层以内就够了，否则ORM查询性能会有明显下降。
3. 关键实操实现：从Django后端到Vue.js前端
3.1 Django项目结构和API设计
项目结构上，我在Django端建了四个app：users负责用户注册登录和画像管理，schools负责院校和专业的数据管理，prediction负责分数线预测相关的接口和算法，recommend负责推荐接口。每个app都保持标准的models.py、views.py、serializers.py、urls.py四件套，代码量控制在可维护的范围内。
API设计遵循RESTful风格，核心接口有这几个：
POST /api/users/register注册，POST /api/users/login登录，返回JWT Token。GET /api/schools/分页获取院校列表，支持keyword、province、level过滤。GET /api/schools/{id}/detail获取院校详情，包含分数线趋势数据。POST /api/prediction/predict接收院校ID和专业ID，触发预测任务，返回最新预测结果。GET /api/recommend/history获取当前用户的历史推荐记录。POST /api/recommend/match接收意向表单，返回推荐列表。
这里重点说一下JWT认证。Django自带的Session认证在前后端分离场景下不够方便，我采用djangorestframework-simplejwt来实现Token认证。前端登录成功后把access_token存在localStorage里，axios请求拦截器统一在请求头上加Authorization: Bearer <token>。刷新Token用POST /api/users/refresh接口，前端在响应拦截器里捕获401状态码后静默刷新。这个认证流程在答辩时很受认可，因为评委能看出你理解前后端分离下的会话保持机制。
Django的ORM查询在多条件筛选时会变得复杂，我的经验是不要恋战，该用django.db.models.Q对象就果断用。比如院校筛选接口需要同时支持按省份、层次、名称模糊搜索，用Q对象组合条件比反复filter().filter()要清晰得多。另外，在删除对象时要注意：Model.objects.delete()是批量删除，会返回一个(total, {app_label.Model: count})的元组；而instance.delete()才返回单一对象的结果。这两个API在Django里经常被混淆，如果你在写删除接口时发现返回结构和预期不一致，多半是混用了这两种写法。
3.2 预测算法后端落地：scikit-learn 模型封装
预测模块在Django里不适合直接在视图函数里跑重计算，因为训练和推理都耗时，而且每次请求都重新计算会拖垮服务性能。我采用的方案是“异步预计算 + 结果缓存”：建一个prediction_tasks表，当用户提交预测请求时，先用Celery异步任务去执行模型计算，计算完成后把结果写入prediction_result表，同时通过WebSocket向前端推送“计算完成”的通知；如果用户请求的是已经预测过的院校，直接从表里读取缓存结果返回，不重复计算。
WebSocket部分我用了Django Channels。这里把实现逻辑讲透：首先安装channels和channels-redis，在settings.py里把ASGI_APPLICATION指向新建的asgi.py，配置Channel Layer使用Redis。然后在consumers.py里写一个PredictionConsumer，继承AsyncWebsocketConsumer，重写connect、disconnect、receive三个方法。前端Vue端用WebSocket原生API连接，连接地址是ws://127.0.0.1:8000/ws/prediction/{user_id}。当Celery任务跑完后，通过channel_layer.group_send向对应用户的消息组发送通知，前端收到消息后自动刷新页面数据。
Celery的接入是另一个关键点。我在Django项目下建celery.py，配置Redis为broker。预测任务的定义用@shared_task装饰器，任务函数内部调用预测算法模块。因为训练模型不能每次任务都重新加载，我把模型对象和scaler对象做了模块级缓存，第一次加载后常驻内存。这个优化在实际运行中效果非常明显。
预测算法内部有两个细节值得展开。第一是特征标准化：因为不同特征的量纲差异很大，比如分数线总分在300到400之间，而院校层次是0到3的整数，如果不做标准化，回归模型的系数解释会出问题，训练收敛也会变慢。这里用sklearn.preprocessing.StandardScaler对特征矩阵统一处理。第二是置信区间的计算：回归预测只是给一个点估计，为了让结果更可信，我用训练集上的残差标准差构造了95%置信区间，前端展示时用ECharts的带状区域来表示。这个设计让预测结果看起来非常专业。
3.3 Vue.js前端实现：ElementUI与ECharts的组合
Vue.js端的工程我用Vite搭建，配Vue Router和Pinia（状态管理）。页面结构分成四个模块：首页数据看板、院校浏览与详情、分数线预测、院校推荐个人中心。
首页数据看板是视觉上的门面，我在这页用了四张ECharts图：全国院校层次分布饼图、近十年国家线趋势折线图、热门专业报考热度柱状图、院校分布地图。这些图的数据都来自后端汇总接口，前端拿到后用ECharts的option配置直接渲染。地图部分需要注意一点：ECharts 5版本开始不再内置中国地图数据，需要单独引入地图GeoJSON，或者使用echarts-countries-js这类包，否则地图渲染会是一片空白。这个坑在开发时花了我一个晚上才定位到，建议大家直接搜索“echarts 中国地图 数据 2024”获取GeoJSON文件，注册到ECharts后使用。
院校详情页是最复杂的页面，顶部是院校基础信息卡，下面用Tab切换展示历年分数表格、分数趋势图、招生人数对比图、相似院校推荐。历年分数表格我使用ElementUI的el-table，数据量大的时候用el-pagination做前端分页；分数趋势图用ECharts折线图，数据源是一个聚合接口，按(school, major)汇总后返回年份序列。
预测页面是一个表单加结果展示的组合。表单部分用ElementUI的表单组件，包括院校选择（级联选择器）、专业选择、预测年份、模型类型选择。提交后进入“预测中”状态，前端开启WebSocket监听后端推送；收到结果后把折线图和指标卡渲染出来。这里交互上有两个细节很关键：第一是表单校验，必须在el-form的rules里配置所有必填项，避免空数据触发后端报错；第二是级联选择器的props配置，院校和专业是父子级关系，对应value和children的字段名必须和后端返回的JSON结构一致，否则组件拿不到数据。
与后端交互的封装我做了统一处理：src/utils/request.js里创建axios实例，配置baseURL、超时时间、请求拦截器（添加Token）、响应拦截器（处理401和业务错误码）。这样所有页面代码都只关心业务数据，不重复处理Token和异常逻辑，代码量减少三分之一以上。
3.4 前后端联调与环境配置
联调阶段最常见的问题是跨域。Django后端默认不允许跨域请求，需要在settings.py里安装django-cors-headers，然后配置CORS_ALLOWED_ORIGINS为前端开发服务器的地址（Vite默认是http://localhost:5173）。开发环境我用Vite的代理功能把/api前缀的请求转发到Django的8000端口，这样浏览器里没有跨域，调试最方便。生产环境则用Nginx做反向代理，把前端静态文件和后端API统一暴露在同一个域名下，彻底规避跨域问题。
项目根目录我写了docker-compose.yml，里面定义了三个服务：Django后端（暴露8000）、Vue前端（用nginx镜像托管dist构建产物，暴露80）、Redis（用于Celery broker和Django缓存）。用Docker Compose一键启动整个系统，在演示环境里非常加分。不过要提醒一句：Docker在生产环境跑通需要一定的Linux基础，如果自己不太熟，建议先在本地跑通，再考虑容器化，不要为了形式上的完整把自己困在部署泥潭里。
4. 大数据环节：从数据采集到可视化
4.1 数据来源与预处理
这个系统的数据来源以公开渠道为主，主要是各院校研究生院官网发布的历年复试分数线通知、研招网公示的招生专业目录、以及一些教育统计网站整理的汇总数据。采集方式上，我写了一套Python爬虫（基于Scrapy），针对不同网站的页面结构定制解析规则；但这里必须强调合规性：采集频率要控制，机器人协议要遵守，数据仅用于学习研究，不能用于商用，论文里要写明数据来源和采集时间。
原始数据的问题主要集中在几个方面。一是数据格式混乱：有的网页用图片展示分数线，需要OCR识别；有的PDF文件里分数线混杂在录取名单中，需要按表格结构重新解析。二是数据缺失：部分院校某几年的数据没有公开，处理策略是用相邻年份的线性插值补全，并在数据表中标注“插值”来源。三是院校合并与更名：比如部分院校从学院更名为大学，代码发生变化，如果不做归一化，时间序列会有断点，预测模型会把断点误判为趋势突变。这一步归一化工作非常繁琐，但对数据质量提升极大。
清洗后的数据我导出了CSV文件作为存档，同时用Django的loaddata或自定义管理命令批量导入数据库。管理命令写在schools/management/commands/import_school_data.py里，读取CSV后按表结构逐行写入，并对重复数据做幂等处理。整套数据流程在系统里是可复现的，这也是答辩时展示“大数据处理能力”的有力证据。
4.2 数据可视化：把分析结果讲清楚
可视化的呈现逻辑要服务于用户决策，而不是单纯炫技。首页看板承担的是“宏观感知”功能，让用户快速看到全国考研的整体格局；院校详情页承担的是“微观分析”功能，让用户了解目标院校的具体情况；推荐结果页承担的是“行动建议”功能，把匹配理由用可视化方式逐条解释。
我在实现时给推荐结果的每一条都配了“推荐原因”区块，用几个小指标卡展示：近三年分数线趋势箭头（上升/下降/平稳）、竞争热度评级（高/中/低）、录取人数变化、用户分数与预测分数差值。这些指标用ElementUI的el-statistic组件加ECharts迷你折线图实现，视觉效果清爽，信息密度也高。这样用户不仅知道“推荐了哪些学校”，还能明白“为什么推荐这些学校”，用户体验和答辩说服力都大幅提升。
4.3 系统里保留的“大数据集群部署策略”讨论
有同学看到热搜词“大数据集群部署策略”可能会觉得自己也得搭一个Hadoop集群。我的观点是：可以讨论，但不必强行上。如果论文篇幅需要，可以在技术展望章节讨论如果数据量达到亿级，这套Django单机架构如何演进——比如使用Redis集群做缓存、用MySQL分库分表、预测任务用Spark MLlib替代scikit-learn、消息队列从Redis扩展为Kafka。这个讨论放在论文里作为扩展方向是加分的，说明你理解系统瓶颈在哪里。但把论文重点放在搭建三节点Hadoop集群而业务系统只是简单统计，答辩时反而容易露馅，因为评委更关心你用技术解决了什么实际问题。
5. 实战避坑：我开发中遇到的高频问题
5.1 环境与依赖版本问题
Django生态的版本兼容性问题在这个项目里碰到的最多。Python版本建议直接用3.10或3.11，Django用4.2 LTS版本，Django REST Framework用最新版，djangorestframework-simplejwt要注意它和DRF版本的匹配关系。Django Channels 4.x 对ASGI的接入方式和3.x差异比较大，如果你在网上找到的教程是旧版写法，很可能启动时报django.core.exceptions.ImproperlyConfigured。遇到这类问题，第一反应是去官方文档对照版本迁移说明，不要盲目改代码。前端这边，ElementUI的组件库要区分Vue2版（element-ui）和Vue3版（element-plus），如果项目创建成了Vue3但安装的是element-ui，整站样式都会完全错乱。
我本地开发用了pipenv管理依赖，把Pipfile和Pipfile.lock一起提交到Git仓库，换电脑或组员协作时执行pipenv install --dev就能复现环境，比手动pip install一个个装要可靠得多。
5.2 CORS与接口联调的坑
前后端联调时的经典报错是浏览器控制台出现No 'Access-Control-Allow-Origin' header is present on the requested resource。如果后端已经装了django-cors-headers，配置了CORS_ALLOWED_ORIGINS仍然报错，请检查中间件顺序：CorsMiddleware必须放在CommonMiddleware之前，否则请求被提前处理导致CORS头加不上。这个顺序问题是文档里明确写了、但初学者最容易忽略的。
另外一个容易被忽略的问题是CSRF。前后端分离模式下，POST、PUT、DELETE请求会被Django的CSRF中间件拦截，返回403。解决方案有两种：要么在DRF设置里配置DEFAULT_AUTHENTICATION_CLASSES使用JWT认证，同时对CSRF接口做豁免；要么在Django设置里把CSRF的TRUSTED_ORIGINS加上前端域名。我推荐用JWT方式，更符合前后端分离的最佳实践。
5.3 ECharts图表不显示数据
ECharts图表开发中，最让人头疼的问题不是配置不会写，而是数据格式对不上。后端返回的JSON结构是一个嵌套对象，比如{ "2020": 350, "2021": 355, "2022": 360 }，而ECharts需要的是两个数组：xData = ["2020", "2021", "2022"]和yData = [350, 355, 360]。我选择在前端做格式化，用Object.keys()和Object.values()拆解后赋值给series.data。还有一种更隐蔽的坑：图表数据里的数值被传成了字符串，ECharts渲染时不会报错，但折线图会全部挤在底部看不出趋势。用Number()做一次类型转换就能解决，这个排查过程花了我一个下午，确认是序列化器字段的类型转换没有生效。
5.4 预测结果可信度的陷阱与答辩应对
预测模块在答辩中几乎一定会被问到：你的预测结果怎么证明是可靠的？我做了三件事来应对。第一，在系统里内置了一个“预测回测”功能，对每个院校专业用历史数据训练、验证最近三年的预测误差，并在详情页展示平均绝对误差（MAE）。第二，在预测结果页展示参考信息：近五年分数线变化、趋势类型、同类院校对比，让预测结果不是孤立数字。第三，在论文中专门写了一段“模型局限性分析”，说明影响分数线的因素非常多，模型只能基于历史数据给出统计意义上的参考。这种坦诚的技术态度比一味夸自己模型准确要好得多，评委也更容易认可。
5.5 源码交付与文档撰写的经验
最后说源码和文档。这类系统的源码体积不小，前端加后端加起来有几百个文件，如果不做版本管理和说明文档，后续自己维护都很痛苦。我会在项目根目录写一个README.md，包含项目简介、技术栈说明、运行前置条件、启动步骤（后端迁移、启动Django、启动Redis、启动前端开发服务器）、默认账号密码、以及目录结构说明。另外一个经验是把关键算法单独抽到utils/目录并写函数级docstring，比如预测模块的predict.py、推荐模块的recommender.py，这样论文里写“系统架构”章节时可以直接引用。
PPT和讲解视频要围绕“提出问题→分析问题→解决问题”的叙事线：先讲考研用户选择院校的痛点，再讲数据从哪来、怎么清洗、怎么分析，接着讲预测模型和推荐策略的选择，最后演示系统界面和运行效果。演示环节要提前准备两套方案：正常演示的必要操作路径，以及万一数据库数据出问题时如何用Admin后台快速修复或直接用预置的截图兜底。
最后再分享一个小技巧：在做预测任务时，把模型训练过程中输出的中间指标也展示出来，比如特征重要性排序、验证误差趋势，这些虽然只是给评委看的“过程数据”，但恰恰是整个系统技术含量的证明。毕竟毕业设计最核心的评价标准不是系统做得有多花哨，而是你对自己做的东西理解得有多深。