企业官网建设流程全解析

又到一年毕业设计选题季，考研分数线预测系统、院校推荐系统这类题目成了计算机专业毕业设计的热门方向。说实话，我当初选这个题，就是冲着它把Django、Vue.js、大数据分析三件事串在了一条线上，既有技术含量又有实际应用场景。如果你也在纠结要不要选这个题，或者已经选了但还在发愁从哪下手，这篇文章应该能帮你把整个脉络从数据到算法到页面到答辩全部捋清楚。

这类系统做完之后的价值，不只是"交一个毕设"这么简单。它覆盖了一条完整的数据链路：数据采集、清洗、存储、分析、建模、可视化、Web展示，每一个环节都能单独拿出来写进简历，答辩的时候也特别容易展开讲。下面我按实际开发顺序，把项目拆成六块内容逐个说透，包括我踩过的坑、验证过的方案、以及为了顺利答辩做过的那些准备。

1. 考研分数线预测系统：题目拆解与核心需求分析

1.1 用户到底需要什么：从考研场景的痛点出发

考研学生在选学校和专业时，最大的痛点不是"没有数据"，而是"数据太散"。国家线、34所自划线院校的分数线、各校复试线、招生人数、报录比，分散在研招网、学校研究生院官网、考研论坛和各种公众号里，格式五花八门，年份口径还不一致。一个学生想对比三所学校的计算机专硕往年分数线，可能要打开十几个网页来回切换。

这个毕设题目要解决的，就是把这个过程收拢到一个系统里。核心用户其实有两类：一类是考研学生，需要快速查到历年分数线、看到趋势图、知道根据自己的情况适合报哪些学校；另一类是管理员，负责维护学校信息、分数线数据、学科目录，保证数据的及时性和准确性。

我当初给系统界定的核心功能就三块：分数线数据管理（增删改查加导入）、分数线趋势预测（基于历年数据建模预测）、院校智能推荐（根据学生输入条件生成匹配列表）。第4块是可视化展示，但这一块本质上是贯穿前三个功能的辅助能力，不需要单独做成一个模块。

1.2 系统边界划定：不做大而全，聚焦能讲清楚的功能

毕设最忌讳的是一上来就想做"考研一站式平台"，社区、论坛、付费咨询、辅导课程都要塞进去。功能越多，每个功能的完成度越低，论文反而越难写。正确做法是先划清边界：这个系统不碰报名、不碰课程销售、不做用户社交，只围绕"分数线"这个核心数据资产来组织。

边界划清楚之后，每个角色要做的事就很明确了。游客可以浏览院校信息和历年分数线；注册用户可以输入自己的预估分数、目标专业、意向地区，生成院校推荐列表和录取概率估算；管理员负责数据维护和预测模型的更新。权限体系用Django自带的认证加上JWT做接口层校验就够了，不需要上复杂的权限框架。

实际操作时我建议再做一层"数据版本"的概念，也就是每一条分数线记录都带一个数据来源和更新时间的标记。这个看起来是小事，但在答辩时非常有用，评委问"你的数据准确吗"，你可以直接说每条数据都能溯源到某个官网页面，比笼统地说"数据来自研招网"有说服力得多。

2. 技术选型底层逻辑：Django + Vue.js + 大数据三者如何配合

2.1 Django：为什么说它是最适合毕设的后端框架

后端框架选择上，Django确实是最省心的一条路。它自带的东西太齐全了：Admin后台可以直接用来做管理员端的数据维护界面，几乎零成本；ORM让数据库操作变成Python对象操作，建表不用手写SQL；自带的认证体系做用户登录注册很顺畅。对毕设来说，"自带电池"这个特点意味着你可以在两三天内跑通主体功能，把宝贵的时间留给算法和文档。

有人可能会问，那用Flask不是更轻量？我的看法是，Flask确实更灵活，但需要自己组装的东西太多。毕设有明确的时间节点，做Flask项目时，你得自己去配扩展、写序列化、处理跨域、搭项目结构，每一步都在消耗时间。而Django的MTV模式非常规整，所有写惯了Java MVC的答辩老师一看就懂，沟通成本低。

我实际开发时的Django版本是3.2 LTS加Python 3.8，这个组合的兼容性很稳定。新版的Django 4.x、5.x虽然特性更新，但网上资料很多还停留在旧版本，遇到问题不容易搜到答案。毕设追求的是稳定靠谱，不是追新。

2.2 Vue.js：前端不是堆页面，而是做交互和可视化

前端选Vue.js，核心原因是它对"数据驱动视图"的支持特别顺手。这个项目里最核心的交互场景是：用户选择年份区间、学科门类后，页面上的趋势折线图、院校对比柱状图要同步更新。如果用传统jQuery去手动操作DOM，每换一次筛选条件就要写一大串DOM更新逻辑，维护起来非常痛苦；Vue的响应式机制让我只需要关注数据层面，界面自动跟着变。

Vue生态里最常用的UI库是Element UI，表格、表单、对话框、分页这些管理后台常见的组件都有现成的。图表方面我用的ECharts，配合vue-echarts封装组件，折线图、柱状图、热力图都能很方便地嵌进页面。

这里要提醒一个新手容易犯的错误：不要在Vue里一股脑把所有页面塞进一个组件。我这个项目分了六个主要页面——登录注册、分数线查询、趋势预测、院校推荐、院校详情、后台数据管理，每个页面都独立成一个Vue组件，用Vue Router做路由管理，页面之间通过路由参数和Vuex共享状态。这个设计后期写论文画架构图的时候也好画，模块边界一目了然。

2.3 大数据在毕业设计里的真实定位

按照大数据架构的经典分层来看，一个完整的大数据体系通常可以分成数据采集层、数据存储层、数据分析层和数据应用层。很多同学一听"大数据毕业设计"，第一反应就是要上Hadoop、Spark、HBase这些东西，结果被集群搭建劝退，最后连基本功能都没做完。

实际上，对考研分数线这个场景来说，数据量级远没到必须上分布式计算的程度。这个题目里的大数据，指的是"大数据思维"和"完整的数据处理流程"，而不是"大数据框架"本身。我把数据采集（爬虫）、数据清洗（Pandas）、数据存储（MySQL）、数据分析（回归模型）、数据可视化（ECharts）这条链路完整走了一遍，这套流程在答辩时完全撑得起"大数据分析"的定位。如果你想向大数据方向稍微靠拢，可以在数据采集阶段引入Scrapy框架，在论文里说明你理解了分布式爬虫的工作原理，虽然实际用了单机，但架构设计的理解是到位的。

3. 数据链路是项目的地基：考研数据的采集、清洗与建模

3.1 数据从哪儿来：公开来源与采集方式

分数线数据的来源是公开的，主要用以下渠道：研招网公布的历年国家线、各院校研究生院官网公布的复试分数线、以及部分教育数据平台上整理的历年汇总表。国家线数据从2010年到上一年度，每年按照哲学、经济学、法学、教育学、文学、历史学、理学、工学、农学、医学、管理学、艺术学等学科门类分别公布学术学位和专业学位的A类、B类分数线，这些数据是预测模型的主力输入。

采集方式上我推荐"半自动"策略：用Python的requests加BeautifulSoup写脚本抓取公开页面，同时准备一份Excel手工校验表作为兜底。因为分数线数据总量并不大，全国所有学科门类加自划线院校的数据也不过几千条，花一个周末手工整理也完全来得及。但既然题目里带"大数据"定位，爬虫脚本还是要写的，这既是技术亮点，也是论文里数据采集章节的支撑材料。

我当时的做法是写了一个crawl_score.py脚本，逐个请求目标URL，把返回的HTML页面解析成结构化数据，输出成CSV文件，再用脚本导入MySQL。这样做的另一个好处是，如果后续需要补充数据，只要改一下年份参数重新跑一遍就能增量更新。

3.2 清洗的坑：年份、学科门类、院校名称

数据清洗是整个项目里最需要耐心的一环，也是最容易在答辩时被问细节的地方。我遇到的第一个坑是年份口径不统一：有些数据源的年份标签是"考试年份"，有些是"入学年份"，两者差一年，如果混在一起做趋势分析，预测结果直接偏掉。统一口径的做法很简单，一律采用"入学年份"作为唯一标准，在清洗脚本里加一个换算函数。

第二个坑是学科门类的多级分类。国家线是按学科门类公布的，但院校线往往精确到学院和具体专业。比如哈尔滨工业大学（深圳）的计算机专硕线，在国家线里对应工学门类，在学校网站里则是"计算机学部"招生。清洗时需要建一张专业到门类的映射表，把专业名称统一归并到13个学科门类下面，否则后期做推荐系统时专业匹配会乱掉。

第三个坑是院校名称的别名问题。"哈尔滨工业大学（深圳）"和"哈工大（深圳）"是同一个人，但字符串不同。我的清洗策略是维护一份院校标准名称表，清洗脚本每小时先做标准化替换，再做去重。这几个坑在论文的数据预处理章节里非常出彩，评委问起来也能回答得很具体。

3.3 数据库设计：四张核心表与关系

数据清洗完成之后进入数据库设计。我给MySQL设计了四张核心业务表：用户表（auth_user，Django自带扩充）、院校表（university）、学科门类表（discipline）、分数线表（scoreline），外加用于推荐系统的报录比统计表（enrollment_rate）。

分数线表是核心中的核心，字段设计大概是这样的结构：

class Scoreline(models.Model): university = models.ForeignKey(University, on_delete=models.CASCADE, verbose_name="院校") discipline = models.ForeignKey(Discipline, on_delete=models.CASCADE, verbose_name="学科门类") year = models.IntegerField(verbose_name="入学年份") score_type = models.CharField(max_length=32, choices=SCORE_TYPE_CHOICES, verbose_name="分数类型") a_class_score = models.IntegerField(null=True, blank=True, verbose_name="A类线") b_class_score = models.IntegerField(null=True, blank=True, verbose_name="B类线") history_total = models.IntegerField(null=True, blank=True, verbose_name="复试总分线") data_source = models.CharField(max_length=200, blank=True, verbose_name="数据来源") updated_at = models.DateTimeField(auto_now=True)

分数类型用choices区分国家线和院校自划线。A类、B类线只有国家线才有，院校自划线只有总分和专业线，设计时用nullable字段兜住这些差异。这个表结构简洁，但能覆盖所有场景，推荐系统的SQL查询也能在单表内完成大部分聚合操作。

4. 核心算法落地：分数线预测与院校推荐

4.1 分数线预测：时间序列思路与代码实现

分数线预测是整个系统里最有"含金量"的部分。我调研之后发现，分数线数据是一个典型的时间序列：每年一个数值，存在总体上涨趋势，但受到当年考题难度、报考人数变化、招生政策调整等因素影响，会有比较大的波动。

最基础的预测方法是线性回归，把年份作为自变量、分数线作为因变量拟合一条直线。但纯线性回归的预测值对波动不敏感，所以我采用了"线性趋势 + 波动修正"的组合方案：先用最小二乘法拟合历年数据的长期趋势线，计算出趋势预测值；再计算近三年的实际值与趋势值的平均偏差，作为修正项叠加到预测结果上。

这部分核心代码我用Pandas加NumPy实现，没有引入重型框架。理由很简单：数据量小、模型可解释、答辩时方便讲清每一步的数学含义。如果用了LSTM，反而需要大量数据支撑且解释困难，容易被评委追问。下面是核心逻辑：

import numpy as np import pandas as pd def predict_scoreline(df, target_year, window=3): # df: 包含year和score两列的DataFrame years = df["year"].values.astype(float) scores = df["score"].values.astype(float) # 最小二乘线性拟合 coeffs = np.polyfit(years, scores, 1) trend_pred = coeffs[0] * target_year + coeffs[1] # 近三年修正项 recent = df.tail(window) recent_deviation = (recent["score"] - (coeffs[0] * recent["year"] + coeffs[1])).mean() return round(trend_pred + recent_deviation, 1)

上线之前，我用最近五年的数据做了回测：用前一年往前所有年份预测接下来的分数线，计算平均绝对误差，大概控制在8到15分之间。这个精度对展示来说已经足够了——因为预测的本质是给趋势判断提供参考，而不是给出精确的录取线。

4.2 院校推荐：多维评分与概率匹配

院校推荐系统的设计思想是"多维度加权评分加概率过滤"。用户输入预估分数、目标专业、意向地区后，系统从数据库中筛选出符合条件的高校，按匹配度从高到低排序。

匹配度计算包含五个维度：地区匹配（目标省市计10分）、分数线贴近度（用户预估分数与院校近三年录取线的差值换算成0到30分）、专业匹配度（目标学科门类与院校招生专业匹配计20分）、报录比宽松度（报录比越高说明竞争越小，换算0到20分）、学校层次（985、211、双一流、普通本科分别给10、8、6、4分）。五个维度加权求和，总分100分。低于60分的直接过滤掉，剩余按分数排序输出。

贴近度的换算逻辑是：预估分数高于录取线越多，得分越高，但不是线性的。我用的分段函数——超过分数线5分以内得20分，5到15分得25分，15分以上得30分；反之低于预估录取线，每低1分扣3分，扣完为止。这套规则我调了两版，第一版是纯线性映射，结果大量低分考生匹配到了顶尖院校，显然不合理；改成段函数之后，推荐结果才符合直觉。

4.3 算法评估：拿历史数据说话

推荐系统做完之后一定要做效果评估，不然答辩时没法回答"你的推荐准不准"。我的评估方式是模拟回测：拿2019年的分数线数据，假设一个预估分数，让系统推荐院校，然后手动检查这些院校2019年实际录取线，看看有多少推荐是合理命中（实际线低于预估分的超过50%）。

第一次回测的命中率只有62%，原因是报录比数据严重缺失，拉低了部分院校的得分。后来我把报录比缺失的院校在评分中做衰减处理，而不是直接给0分，命中率提升到了78%。这个调优过程成了论文实验章节的亮点，也让我在答辩时有了真实的迭代数据可以讲。

5. Django后端与Vue.js前端实战：从建项目到联调排错

5.1 Django项目工程化：apps划分与核心模型

Django的项目结构我会强烈建议大家按app来划分功能，而不是所有模型堆在一个app里。我这个项目建立了users（用户）、universities（院校管理）、prediction（分数线预测）、recommendation（推荐服务）四个app，每个app只负责自己领域内的模型、视图、序列化器。

创建项目的命令很简单，但操作上有个习惯值得养成：

django-admin startproject graduate_project cd graduate_project python manage.py startapp users python manage.py startapp universities python manage.py startapp prediction python manage.py startapp recommendation

每创建一个app，第一件事就是去settings.py的INSTALLED_APPS里注册。少了这一步，Django会静默忽略你的模型定义，迁移和ORM查询都找不到表。这个坑我当年踩过一次，排查了半天，最后发现就是没注册app。这类环境问题在答辩前特别容易让人心态崩溃，所以我把常见的Django环境问题整理成了一个自查清单：1. app是否注册；2. 虚拟环境是否激活；3. 数据库连接配置是否生效；4. 迁移命令是否执行成功。

模型层除了前面说的Scoreline，还有University和Discipline。University需要处理院校名称标准化，Discipline要维护学科门类和代码。三者之间用外键关联，查询时用Django ORM的select_related和prefetch_related避免N+1查询问题，这些优化的代码细节在答辩时也可以作为性能优化点讲。

5.2 接口设计与JWT认证

前端和后端的接口交互全部走RESTful API。我用的Django REST framework（DRF）做序列化和视图集，接口按资源划分：

• POST /api/auth/register 注册
• POST /api/auth/login 登录，返回JWT token
• GET /api/universities 院校列表，支持按地区、层次筛选
• GET /api/scorelines 分数线列表，支持按院校、年份、学科筛选
• POST /api/predictions 提交预测请求，返回分数线预测结果
• POST /api/recommendations 提交推荐请求，返回院校推荐列表

认证用的是SimpleJWT库，前端登录后把token存到localStorage，axios请求拦截器里带上Authorization头。这里有一个新手容易犯的错误：忘记在DRF的DEFAULT_PERMISSION_CLASSES里设置IsAuthenticated，导致所有接口裸奔，没登录也能访问。设置好权限之后，再配合CORS跨域配置，前后端联调才能顺畅。

接口文档我用DRF自带的schema生成得了API文档页面，答辩时直接打开页面展示接口定义，比自己贴Word文档专业很多。

5.3 Vue.js项目搭建与可视化页面

前端我用的Vue CLI搭建项目骨架，切换到Vite也可以，但保证开发环境和网上资料匹配很重要，我当时选了Vue CLI 4.x，稳定不出幺蛾子。项目结构上分为views（页面组件）、router（路由配置）、store（Vuex状态）、api（axios封装）和components（复用组件）五个目录。

页面核心就是分数线查询和趋势预测页。查询页用Element UI的表格组件展示数据，筛选条件放侧边栏，支持按学科门类、年份、院校名称三个维度组合筛选。趋势预测页用ECharts的折线图展示历年分数线变化，预测年份用虚线和橙色点单独标出，视觉上非常直观。

ECharts接入的代码拆成组件会更优雅。我封装了一个LineChart组件，接收父组件传入的series数据和年份标签，内部维护ECharts实例。父组件只要更新数据，图表就自动刷新，不需要每个页面重复写ECharts初始化代码。这种组件化思维在文档里也要重点体现。

5.4 前后端联调与常见排错

联调阶段最容易出的问题集中在三处：跨域、静态资源路径、开发环境端口冲突。

跨域解决不复杂，给Django安装django-cors-headers，在settings.py里配置CORS_ALLOWED_ORIGINS成前端地址即可。如果前端用了代理模式，还需要在vue.config.js里配置devServer.proxy，把/api开头的请求转发到后端端口，这个方案在开发环境更干净。

静态资源问题我认为是Vue项目里的高频坑。比如说Vue前端打包后，图片路径默认是相对路径，部署到Django的static目录时容易404。解决方案在vue.config.js里设置publicPath为'./'，并且用Django的{% static %}模板标签配合前端引用。如果你在VS Code里写img标签，src引用Django的static文件却显示不了，多半是路径没走模板解析，或者是Django的STATICFILES_DIRS配置漏了你的自定义静态目录。

还有一个很隐蔽的坑：前端页面访问后端接口时出现"Missing Token"报错，检查后发现在登录成功后没有把token写入axios的公共header。这个随便都能搜到，但真正隐蔽的是——如果你用了多个浏览器标签页，一个标签页退出登录导致token失效，另一个标签页还在用旧token发请求，表现就是偶尔401偶尔正常。后来我在axios响应拦截器里统一处理401，发现就自动跳转登录页，这个问题才算根治。

6. 交付不只是代码：源码、文档、PPT、答辩的系统化准备

6.1 源码组织与README写作规范

毕业设计提交源码的时候，老师第一眼看的不是代码写得多漂亮，而是项目结构是否清晰、能不能跑起来。我建议在项目根目录写一份详细的README.md，内容包括：开发环境版本（Python、Django、Node、MySQL）、数据库初始化步骤、依赖安装命令、启动命令、默认管理员账号。这份README能让你在答辩演示时节省大量时间，也让评委对你的工程素养有正面印象。

源码目录最好做到"后端前端分开、App按功能命名、配置文件和源码分离"。我见过很多同学把虚拟环境目录venv也提交上去，压缩包几百兆，非常不专业。正确做法是在.gitignore里排除venv、node_modules、pycache、.idea这类目录，只提交必要文件。

6.2 毕业论文结构怎么安排

论文结构是答辩的另一个权重项。我当时的章节安排是：第一章绪论（研究背景、国内外现状、研究意义），第二章相关技术介绍（Django、Vue.js、大数据处理技术），第三章系统需求分析（功能性需求、非功能性需求、用例图、流程图），第四章系统设计（总体架构、功能模块设计、数据库设计、算法设计），第五章系统实现（前后端实现、核心代码、界面截图），第六章系统测试（功能测试、性能测试、算法效果评测），第七章总结与展望。

最关键的是第四章和第五章，算法设计和系统实现要结合真实数据和代码截图，不能空谈。我在算法设计章节里放了预测模型的公式推导、推荐算法的权重设计，在系统实现章节里贴了核心接口代码和页面截图。这样的论文查重率也容易控制，因为模型推导和自己项目的截图都是原创的。

6.3 PPT与演示讲解经验：十分钟把亮点讲清楚

答辩PPT我建议控制在15页以内，按"背景需求一页、技术架构一页、数据库设计一页、算法讲解三页、系统演示八页、总结一页"的节奏来。页数少但每页信息量要足，特别是算法那三页，要画清楚预测模型的流程和推荐系统的评分公式，让评委不需要动脑就能理解你的思路。

演示环节的要点是"先完成整体展示，再深入亮点"。我会先跑一遍完整的用户流程：注册、登录、查询分数线、发起预测、生成推荐列表，让大家看到系统能用。然后再回到预测模块，解释修正项的来源；回到推荐模块，解释权重怎么调节。在推荐结果页我还会现场演示调参，把地区匹配权重从10改成20，展示排名变化，这个动效给评委的冲击力很强。

最后一个建议：一定要录一份五分钟的演示视频备份。答辩现场突发情况很多，曾经遇到过电脑不识别VGA转接头、投影仪只有HDMI口而电脑没有、教室网关断了接口登不上后台等各种状况，有视频在手，至少保证讲解不断档。我把启动项目、正常演示、异常输入的兜底提示都录在一个视频里，放在PPT最后一页的超链接上，这个细节当时被答辩组长点名表扬过。

回看整个项目的开发过程，最有价值的经验其实是"把每个决策的理由想清楚"。选Django是因为它的生态完整，能让毕设从零到一快速跑通；选Vue.js是因为数据驱动视图的特性特别适合分数线可视化；把"大数据"定位成完整数据处理链路而不是堆分布式框架，是贴合场景的务实判断。如果你能顺着这个思路把系统做出来，答辩时每个问题都可以讲到技术的本质层面，而不是停留在"我用了什么工具"的表面，这套准备就足够扎实了。