拓冰网站定制 
从0到1搭一个PythonVue的高考志愿智能推荐系统真实项目复盘高考志愿这件事每年都有一千多万家庭在纠结。学校那么多、专业那么杂往年录取数据堆成山靠手工翻书一个个比对效率低不说还经常遗漏关键信息。我之前接过一个课题就是做一个高考志愿智能推荐系统——后端用PythonDjango/Flask二选一前端用Vue开发工具用PyCharm最终效果是输入考生的分数、位次和选科组合系统自动匹配出“冲稳保”三档院校清单并附带专业推荐。这篇文章就把我这次项目从需求拆解、技术选型到编码落地的全过程记录下来包括那些只有实际动手才会踩到的坑。内容面向有Python和前端基础、想做全栈实战项目的开发者也适合准备做毕设的同学直接抄作业。先说结论这个项目不算难但涉及的层次很全——数据清洗、算法设计、接口联调、前后端分离、部署上线都有是典型的“麻雀虽小五脏俱全”型全栈实战。技术栈我最终定的是 Django Vue PyCharm为什么没选Flask后文会展开说。整个系统跑通后输入“物理化学生物、600分”这类条件几十秒内就能输出一份可打印的填报参考方案。1. 项目全貌与需求拆解1.1 这个系统到底在解决什么问题先想清楚一个问题高考志愿填报的痛点是什么信息过载。每年各省考试院会公布“一分一段表”各院校会公布投档线和录取位次但这些数据散落在不同平台格式还不统一。家长和考生要做的核心决策其实是回答三个问题我的分数能报哪些学校这些学校哪些专业适合我录取概率有多大这三个问题翻译成技术需求就是能根据考生分数和位次筛选出历年录取位次在考生位次附近的院校列表能结合考生的选科组合过滤掉不满足科目要求的院校和专业能通过某种算法把院校分成“冲一冲”“稳一稳”“保一保”三档最好还能做一个简单的兴趣测评给考生推荐匹配的专业方向。所以这个系统的本质就是一个**“规则引擎 数据匹配 可视化展示”**的查询系统而不是什么高深的人工智能。搞清楚这一点整个项目的复杂度一下就降下来了——绝大部分工作量在数据清洗和界面交互上而不是算法本身。1.2 用户角色与核心流程设计系统有两种用户考生和家长前台管理员后台。考生的操作流程我设计成了四步注册登录完善个人信息分数、位次、选科、省份系统根据信息自动完成数据匹配生成推荐列表用户可以通过省份、院校类型、专业方向等条件二次筛选点击院校查看近三年录取趋势、专业分数线、选科要求和就业方向。管理员端就简单多了批量导入每年的录取数据、维护院校专业库、管理用户反馈。这四条流程定下来前端路由、后端接口、数据表结构就都有方向了。我不会一上来就写代码而是先画了一张简单的数据流图用户输入 → 后端算法模块 → 数据库查询 → 结果封装 → Vue前端渲染。后续所有开发都围绕这条链路展开。2. 技术选型的幕后逻辑Django还是Flask2.1 后端框架对比与最终决策看到标题里的“django flask”说明很多人在纠结到底用哪个。我把两个框架的对比直接列出来对比维度DjangoFlask生态完整性自带ORM、Admin后台、认证、表单需要自己装扩展学习曲线较陡概念多平缓容易上手适合场景中大型项目后台管理需求多的轻量API服务微服务数据建模models.py声明式迁移方便需配SQLAlchemyAdmin后台一行代码生成后台需要第三方库这个项目里有一个硬性需求管理员要批量管理几千条院校录取数据。Django自带的Admin后台可以直接复用配好模型之后增删改查、批量导入导出、权限控制全都有了——这些功能如果从零写至少要一周工作量。所以我的建议很明确凡是像这样“有数据管理后台需求”的项目闭眼选Django如果只是做一个纯API服务Flask更轻快。另外说一句用Django还有一个隐形好处它的ORM自带了数据库迁移机制我开发中改了三四次表结构都是python manage.py makemigrations一行命令同步省了大量手工改表的时间。这个体验在FlaskSQLAlchemy里虽然也能实现但没这么顺滑。2.2 为什么是Vue PyCharm 全家桶前端选Vue核心原因是组件化和渐进式引入。这个项目最复杂的界面是“院校列表 条件筛选 图表展示”Vue的组件化开发能把“筛选条件栏”、“院校卡片”、“录取位次趋势图”拆成独立组件各管各的状态互不干扰。PyCharm的价值则体现在两个地方一是对Django的“开箱即用”支持——创建项目时直接有Django模板运行配置、模板调试、ORM模型检查都是图形化的二是它的数据库工具很顺手我右键就可以查看数据表记录不用切到Navicat。这里插一句PyCharm的Professional版是商业软件学生可以申请免费授权这也是我推荐学生党优先考虑PyCharm的原因。技术栈最终定为后端Python 3.10 Django 4.x Django REST Framework前端Vue 3 Vite Element Plus Axios ECharts数据库MySQL开发期用SQLite就够了部署换MySQL开发工具PyCharm Professional2.3 解决“选科”这个新高考特有的问题如果只看老高考的“文科/理科”二分法这个系统会非常简单。但新高考改革后大部分省份实行“312”模式选科组合直接决定了你能报哪些专业。比如临床医学通常要求“物理化学”而历史类考生基本与计算机专业无缘。这意味着数据表里必须增加选科要求字段匹配逻辑也不是简单的分数比较。我设计了一个subject_requirement字段存的是类似“物理|化学”的字符串匹配时先拆分再逐一检查考生选科是否覆盖。这块逻辑不复杂但容易漏——遇到个别院校专业“物理或化学任选其一”的情况就得单独处理这个细节我后面在“常见问题”里还会提到。3. 核心算法与数据库设计推荐怎么才算“准”3.1 位次法分数会贬值位次不会志愿填报圈里有一句老话——“看分没意义看位次才靠谱”。为什么因为每年考题难度不同同一所学校的录取分数线会波动但录取考生的省排名位次相对稳定。比如某校去年录取最低分是590今年可能涨到605但对应的位次基本都在全省8000名左右。所以系统的核心算法用的是位次匹配。具体逻辑是这样的用户输入高考分数和全省位次系统用考生位次去比对各院校近三年的最低录取位次计算出一个“位次差”指标——考生位次比院校录取位次高越多录取概率越大根据位次差区间自动归类为“冲、稳、保”三档。我用Django的ORM来实现这个逻辑核心代码如下def match_schools(student_rank, student_subjects, province): # 获取所有院校的最低录取位次 schools AdmissionScore.objects.filter( provinceprovince ).values(school_id, year, min_rank) # min_rank为该年最低录取位次 # 计算近三年平均最低位次 rank_map {} for item in schools: key item[school_id] rank_map.setdefault(key, []).append(item[min_rank]) result [] for school_id, ranks in rank_map.items(): avg_rank sum(ranks) / len(ranks) # 近三年平均最低位次 # 考生位次比平均位次高(数字小)概率大 diff avg_rank - student_rank school School.objects.get(idschool_id) # 选科过滤 if not check_subjects(school.requirement, student_subjects): continue if diff 5000: level 保 elif diff -2000: level 稳 else: level 冲 result.append({ school: school, avg_rank: int(avg_rank), diff: int(diff), level: level, # 历年数据 history: [r for r in ranks] }) result.sort(keylambda x: x[avg_rank]) return result这段代码里有个细节我要说一下diff 5000意味着考生位次比院校平均位次高5000名也就是说考生有足够的余量录取概率很大归为“保”diff -2000时考生虽然比平均位次低一点但在可接受范围内归为“稳”如果比平均位次低超过2000名就属于冲刺了。很多人会问这些阈值是拍脑袋定的吗其实不是这是根据往年经验调出来的。不同省份考生密度不一样5000名在考生大省可能只值几分在考生少的省份可能就是几十分了。所以我把阈值抽成了配置项方便按省份调整# config.py THRESHOLD { rush: -2000, # 低于平均位次这个值以内算冲刺 safe: 5000, # 高于平均位次这个值以上算保底 }这种设计方式值得所有做推荐类项目的人参考核心算法先把“能不能跑通”解决再把“参数可调”跟上不要一上来就追求完美。先用固定规则跑通再根据测试结果慢慢调参这是最务实的做法。3.2 专业推荐不搞“智能”搞“测评 规则”说实话市面上的“智能测性格选专业”多数是噱头但我还是在系统里做了一个简化版专业推荐模块。思路是借用了霍兰德职业兴趣测试的六型分类模型实用型R、研究型I、艺术型A、社会型S、企业型E、常规型C做了一个20道题的简化问卷。用户做完后计算得出自己的主导类型组合。然后我把专业库里的每个专业都打上了类型标签比如“计算机科学与技术”偏研究型I和企业型E“护理学”偏社会型S和实用型R。用户测评完系统按匹配度排序输出推荐专业清单。技术实现上没什么难度就是两张表之间的多对多关联但这里我想强调一个产品逻辑测评只是辅助决策不能代替数据。所以我在前端展示时特意把专业推荐和录取数据推荐放在两个独立模块里一个解决“我喜欢什么”一个解决“我能上什么”最后让用户自己平衡。这个设计在后来的试用反馈里被多次点赞说比那些把“喜欢”和“能上”揉在一起的系统靠谱得多。3.3 数据模型设计六张核心表项目的数据模型我从一开始就定了六张核心表这里直接贴出来# models.py节选 from django.db import models class Province(models.Model): name models.CharField(max_length32, uniqueTrue) gaokao_type models.CharField(max_length16) # 312 / 33 / 文理分科 class School(models.Model): name models.CharField(max_length128) province models.ForeignKey(Province, on_deletemodels.CASCADE) school_type models.CharField(max_length32) # 综合/理工/师范/医药等 is_985 models.BooleanField(defaultFalse) is_211 models.BooleanField(defaultFalse) is_double_first_class models.BooleanField(defaultFalse) subject_requirement models.CharField(max_length64) # 如 物理|化学 class Major(models.Model): name models.CharField(max_length128) code models.CharField(max_length8) category models.CharField(max_length32) # 工学/理学/管理学等 holland_types models.CharField(max_length16) # 如 RI class SchoolMajor(models.Model): school models.ForeignKey(School, on_deletemodels.CASCADE) major models.ForeignKey(Major, on_deletemodels.CASCADE) subject_requirement models.CharField(max_length64, blankTrue) # 一个学校同一个专业在不同省份招生人数不同 plan_count models.IntegerField(default0) class AdmissionScore(models.Model): school models.ForeignKey(School, on_deletemodels.CASCADE) major models.ForeignKey(Major, on_deletemodels.CASCADE, nullTrue, blankTrue) province models.ForeignKey(Province, on_deletemodels.CASCADE) year models.IntegerField() # 2022/2023/2024 min_score models.IntegerField(default0) # 最低分 min_rank models.IntegerField(default0) # 最低位次 avg_score models.FloatField(default0) # 平均分 class UserProfile(models.Model): user models.OneToOneField(auth.User, on_deletemodels.CASCADE) province models.ForeignKey(Province, on_deletemodels.SET_NULL, nullTrue) score models.IntegerField(default0) rank models.IntegerField(default0) subjects models.CharField(max_length32) # 如 物理|化学|生物这里有个设计细节值得展开AdmissionScore表里我存了major外键且允许为空。原因是一个院校的投档线和具体专业的录取线是两回事——有些省份只公布院校最低投档线有些省份会公布到具体专业。字段允许为空的好处是即使全省数据只拿到院校层面的也能正常入库使用以后补录了专业数据也不影响如果一开始就设为非空导入数据时遇到缺失就要做额外处理平白增加工作量。这也是做数据处理项目时的一个通用心得不要把表的严谨性建立在“数据一定完整”的假设上。3.4 近三年位次趋势的核心查询算法里还有一个高频操作查某个学校某专业近三年的录取位次。这个查询在Django ORM里写很简单但有个性能优化点要提醒一下——不要循环里查数据库。我踩过这个坑第一次实现时在match_schools的循环里每个学校各查一次AdmissionScore本地测试几百条数据不觉得慢等导入真实的两千多条数据后接口响应直接飙到十几秒。正确的做法是批量查询把要查的学校ID收进一个列表一次性取出来在内存里分组# 正确姿势 school_ids [s.id for s in schools] all_scores AdmissionScore.objects.filter( school_id__inschool_ids, year__in[2022, 2023, 2024] ).order_by(school_id, year) # 内存中按学校分组 from collections import defaultdict score_map defaultdict(list) for score in all_scores: score_map[score.school_id].append(score)这个改动让接口耗时从十几秒降到几百毫秒量级直接改变。N1查询问题是每个Django API开发者的必修课这个项目就是最好的练手场景。4. 实操落地从工程创建到页面联动4.1 环境准备与Django工程初始化先说环境我用的是PyCharm Anaconda组合。Anaconda的好处是创建虚拟环境方便不污染系统Python。我建议每个项目单独建环境# 创建并激活虚拟环境 conda create -n gaokao python3.10 -y conda activate gaokao # 安装依赖 pip install django djangorestframework mysqlclient celery django-cors-headers pandas openpyxl然后在PyCharm里新建Django项目。这里有个小提示如果你用的是PyCharm Professional直接选Django模板生成会自动配置好settings.py、urls.py和manage.py的结构如果用Community版用命令创建也一样django-admin startproject gaokao_system cd gaokao_system python manage.py startapp api python manage.py startapp users项目结构我分了几个应用appgaokao_system/ ├── gaokao_system/ # 项目配置 ├── api/ # 核心接口院校匹配、专业推荐 ├── users/ # 登录注册、个人资料 ├── data/ # 数据导入与管理 ├── static/ # Vue前端打包后的静态文件 └── templates/ # Vue的index.html入口为什么拆多个app而不是全堆在一个里因为Django的app本质上就是模块边界。志愿匹配和数据导入是两个完全不同的功能域拆开之后代码清晰出了问题也好排查。这不是装模作样的规范是真的能省心。4.2 数据导入Pandas一把梭数据从哪来我的做法是从各省考试院官网和公开数据集里收集CSV/Excel文件然后用Pandas清洗、入库。这里分享一个数据清洗的经典流程# data/import_scores.py import pandas as pd from api.models import School, AdmissionScore, Major df pd.read_excel(sichuan_2024.xlsx) # 1. 去重 df df.drop_duplicates(subset[school_name, major_name, year]) # 2. 处理缺失值位次缺失的按分数降序填充规则处理 df[min_rank] df[min_rank].fillna(0).astype(int) # 3. 清洗专业名称中的空格和特殊字符 df[major_name] df[major_name].str.strip().str.replace(r\s, , regexTrue) # 4. 逐个入库 for _, row in df.iterrows(): school, _ School.objects.get_or_create( namerow[school_name], defaults{...} ) major, _ Major.objects.get_or_create( namerow[major_name], defaults{category: row.get(category, 未知)} ) AdmissionScore.objects.create( schoolschool, majormajor, province_idprovince_id, yearrow[year], min_scorerow[min_score], min_rankrow[min_rank], avg_scorerow.get(avg_score, 0) )这里用get_or_create()而不是先查后建避免了重复ID的坑。而且数据导入是个会反复执行的操作幂等性很重要——你导错了改个数据再跑一遍不应该产生重复记录。4.3 Django REST Framework写推荐接口匹配接口是系统的心脏我用DRF的APIView写逻辑清晰也方便后面加权限控制# api/views.py from rest_framework.views import APIView from rest_framework.response import Response from rest_framework.permissions import IsAuthenticated class RecommendView(APIView): permission_classes [IsAuthenticated] # 需要登录 def post(self, request): user request.user # 优先用请求参数没有则用用户已存的资料 score request.data.get(score, user.userprofile.score) rank request.data.get(rank, user.userprofile.rank) subjects request.data.get(subjects, user.userprofile.subjects) # 解析选科 subject_list subjects.split(|) # 匹配院校 results match_schools(rank, subject_list, user.userprofile.province) return Response({ code: 0, data: { total: len(results), list: results[:50], # 一次最多返回50条 threshold: THRESHOLD, } })接口写好后用PyCharm自带的HTTP Client或者Postman就能直接测试。这里有一个调试习惯想推荐先写死数据测接口再动态传参。我开发时是先在Django shell里把match_schools函数用几组有代表性的分数测一遍比如600分/位次8000、560分/位次12000、500分/位次22000确认匹配结果合理再挂到接口上。这样排查问题时会很容易区分是算法问题还是接口问题。4.4 Vue前端搭建项目与页面路由Vue项目我用Vite脚手架创建npm create vitelatest frontend -- --template vue cd frontend npm install vue-router axios element-plus echarts为什么用Vite不用Vue CLI因为Vite冷启动快依赖预构建也更智能Vue CLI已经处于维护模式新项目没必要再选它。Element Plus是Vue 3配套的组件库搭列表、表单、标签页很快ECharts用来画录取位次趋势图。页面路由设计如下// router/index.js import { createRouter, createWebHistory } from vue-router const routes [ { path: /, redirect: /recommend }, { path: /login, component: () import(../views/LoginView.vue) }, { path: /recommend, component: () import(../views/RecommendView.vue) }, { path: /school/:id, component: () import(../views/SchoolDetailView.vue) }, { path: /major-test, component: () import(../views/MajorTestView.vue) }, { path: /admin, component: () import(../views/AdminView.vue), meta: { admin: true } }, ]这里用到Vue的动态路由——/school/:id这个路由用户点击某个院校卡片后前端根据id参数跳转到详情页详情页再用this.$route.params.id去调后端接口拉取该校近三年录取数据并画ECharts图。这个交互几乎每一个数据列表类项目都会用到值得重点练熟。4.5 前端与后端联调跨域问题一次解决前后端分离开发时Vue跑在localhost:5173Django跑在localhost:8000端口不同浏览器会拦跨域请求。后端装django-cors-headers并配置# settings.py INSTALLED_APPS [ # ... corsheaders, ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, # ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, ]注意CorsMiddleware要放在CommonMiddleware之前不然中间件顺序不对会导致跨域配置不生效。这个坑我栽过后来看日志才发现是顺序问题。前端这边只需要用Axios统一配置baseURL// api.js import axios from axios const request axios.create({ baseURL: http://localhost:8000/api, timeout: 10000 }) // 请求拦截器自动携带token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Token ${token} } return config })Token认证我用的Django REST Framework自带的TokenAuthentication简单可靠。JWT虽然功能更多但对这个量级的项目来说反而显得笨重——Token生效快、调试直观安全性完全够用。4.6 推荐结果的前端展示与动态筛选推荐结果页是用户看得最多的页面我做了“卡片式列表 多条件筛选 分页”三个功能。卡片上显示院校名称、省份、综合标签985/211/双一流、近三年平均最低位次、冲稳保等级等级用不同颜色标签区分——冲是红色、稳是黄色、保是绿色。这个设计符合填报时的心理预期。筛选条件栏包括省份、院校类型、是否有985/211标签、冲稳保等级、专业关键字。核心逻辑用computed属性实现把筛选条件变化映射成列表过滤template div classschool-grid SchoolCard v-forschool in filteredSchools :keyschool.id :schoolschool clickgoDetail(school.id) / /div /template script setup import { ref, computed } from vue import SchoolCard from ../components/SchoolCard.vue const schools ref([]) // 后端返回的原始数据 const filters reactive({ region: , type: , level: , keyword: }) const filteredSchools computed(() { return schools.value.filter(s { if (filters.region s.region ! filters.region) return false if (filters.type s.school_type ! filters.type) return false if (filters.level s.level ! filters.level) return false if (filters.keyword !s.majors.some(m m.includes(filters.keyword))) return false return true }) }) /script用computed而不是methods是因为筛选是纯依赖数据的高频计算computed会缓存结果性能表现更好。这个细节对前端新手来说很实用——什么时候用computed、什么时候用watch是Vue面试最常问的知识点之一。4.7 部署上线从开发环境到服务器开发完成后要部署到服务器我用的是Nginx uWSGI MySQL组合。Django侧的关键步骤# 收集静态文件 python manage.py collectstatic # 安装uwsgi pip install uwsgiuWSGI配置文件[uwsgi] chdir /srv/gaokao_system module gaokao_system.wsgi:application master true processes 4 threads 2 socket 127.0.0.1:8001 vacuum trueNginx负责托管Vue打包后的静态文件和反向代理API请求# nginx.conf server { listen 80; server_name your_domain.com; # Vue前端静态文件 root /srv/gaokao_system/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; # 解决Vue路由刷新404问题 } # API反向代理 location /api/ { proxy_pass http://127.0.0.1:8001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;这行配置是Vue项目部署的精髓——前端路由在刷新时会向服务器发起资源请求如果不回退到index.html就会出现404。所有Vue SPA项目上线时都要检查这一行有没有写对。5. 常见问题与排错实录5.1 N1查询导致接口响应慢前面讲算法优化时提到过N1查询问题这里再展开说。初始版本里match_schools函数每次循环都会去查一次学校详情、一次专业列表导致代码虽然“看起来没问题”实际性能一塌糊涂。排查过程是这样的先在浏览器Network面板里看到接口耗时12.7秒然后用Django的connection.queries打印出SQL语句数量发现一个请求引发了2000多条SQL。这就是典型的循环内查库——每查一条数据发一次数据库请求。解决方案就是前面提到的批量查询把所有学校ID收集起来一次查完再在内存里组装。优化后SQL数量降到个位数接口耗时降到400毫秒。衡量ORM写得好不好的金标准就是看SQL查询次数。5.2 选科匹配边界遇到“或”关系怎么办新高考选科要求里有一种情况特别容易写错专业要求“物理或化学”意思是考生选了其中任何一科就满足条件。如果用我前面那种“集合包含”的简单判断会把这种情况误判为不满足。我加了一个解析函数把要求拆成“必须满足的一组”和“任选其一的一组”def check_subjects(requirement_str, selected_subjects): if not requirement_str: return True selected_set set(selected_subjects) # 按“且”关系拆分 for and_group in requirement_str.split(): group and_group.replace((, ).replace(), ) if | in group: # “或”关系任一满足即可 if not (selected_set set(group.split(|))): return False else: if group not in selected_set: return False return True这个函数属于典型的“看起来简单但容易漏”的逻辑。我的建议是写完立刻用测试用例验证——物理化学生物、物理政治地理、历史生物政治每种组合各跑一遍覆盖住主要情况再继续往下做功能。5.3 Vue打包后路由404部署阶段遇到一个经典问题把npm run build生成的dist目录放到Nginx后首页能打开但一旦刷新/school/102这种详情页就报404。原因我在上文的Nginx配置里已经点到了——单页应用的路由是前端切出来的服务器上并没有对应的/school/102这个物理路径所以Nginx默认会返回404。一个try_files指令解决的location / { try_files $uri $uri/ /index.html; }现在很多新手喜欢用hash模式路由/#/school/102这种方式刷新确实没这个问题但URL里带着#号非常不好看也不利于SEO。我的建议是用history模式Nginx回退配置一步到位。5.4 数据库日期字段的“取年份”陷阱在统计近三年录取趋势时我用Django ORM取年份一开始写的是score.year.year结果发现这是SQLite里DateField的类型转换问题——score.year如果定义成IntegerField就不会有这个问题但如果定义了DateField在SQLite下取年份就要注意处理。我的建议是录取数据里的年份直接用IntegerField这只是一个展示和对比维度没必要用DateField。6. 经验沉淀如果让我重做一遍的改进清单几次测试下来系统基本达到了当初的定位数据准确、推荐有依据、交互顺滑。但站在总结经验的角度有几个地方如果重做一遍我会做得更好。第一数据源的持续性设计应该提前做。每年高考录取数据更新一次靠手工下载Excel再导入不是长久之计。如果正式上线应该做一个爬虫模块定时从省考试院网站抓取数据或者至少做一个“管理员上传Excel后自动增量更新”的功能而不是像现在这样半手动导入。第二推荐结果的解释性可以更强。现在系统只告诉用户“这是稳档”但没有解释为什么——比如可以展示“该校近三年最低位次分别为9000、9500、8800您的位次为8000在过去三年中均高于录取线”这类文本说明让用户信服。我当初因为时间原因没做这个模块但试用的几位朋友都不约而同问过“为什么这个学校是稳的”这让我意识到推荐系统的置信度说明比推荐本身更重要。第三性能优化还可以再进一步。目前match_schools每次请求都对全量院校做计算数据量再大一点就该考虑把“位次匹配”的结果提前算好存入缓存或者用Redis做一层缓存。对于当前几千条数据来说没必要但架构上要留出这个空间。最后一条建议给所有想做类似系统的朋友做这类偏数据展示的系统第一优先级是把主流程跑通而不是追求算法花哨。先用一个最简单的规则匹配做完最核心的查询流程让用户能输入、能看到结果、能筛选就已经是一个完整的MVP了。至于更精准的算法、更智能的推荐那是在PV基础上一步步迭代的事。我在这个项目里最大的感触就是真正消耗时间的不是代码本身而是数据清洗和排错这两件事做得越扎实系统就越经得起用。 Python+Vue高考志愿智能推荐系统：基于位次匹配的全栈实战方案
从0到1搭一个PythonVue的高考志愿智能推荐系统真实项目复盘高考志愿这件事每年都有一千多万家庭在纠结。学校那么多、专业那么杂往年录取数据堆成山靠手工翻书一个个比对效率低不说还经常遗漏关键信息。我之前接过一个课题就是做一个高考志愿智能推荐系统——后端用PythonDjango/Flask二选一前端用Vue开发工具用PyCharm最终效果是输入考生的分数、位次和选科组合系统自动匹配出“冲稳保”三档院校清单并附带专业推荐。这篇文章就把我这次项目从需求拆解、技术选型到编码落地的全过程记录下来包括那些只有实际动手才会踩到的坑。内容面向有Python和前端基础、想做全栈实战项目的开发者也适合准备做毕设的同学直接抄作业。先说结论这个项目不算难但涉及的层次很全——数据清洗、算法设计、接口联调、前后端分离、部署上线都有是典型的“麻雀虽小五脏俱全”型全栈实战。技术栈我最终定的是 Django Vue PyCharm为什么没选Flask后文会展开说。整个系统跑通后输入“物理化学生物、600分”这类条件几十秒内就能输出一份可打印的填报参考方案。1. 项目全貌与需求拆解1.1 这个系统到底在解决什么问题先想清楚一个问题高考志愿填报的痛点是什么信息过载。每年各省考试院会公布“一分一段表”各院校会公布投档线和录取位次但这些数据散落在不同平台格式还不统一。家长和考生要做的核心决策其实是回答三个问题我的分数能报哪些学校这些学校哪些专业适合我录取概率有多大这三个问题翻译成技术需求就是能根据考生分数和位次筛选出历年录取位次在考生位次附近的院校列表能结合考生的选科组合过滤掉不满足科目要求的院校和专业能通过某种算法把院校分成“冲一冲”“稳一稳”“保一保”三档最好还能做一个简单的兴趣测评给考生推荐匹配的专业方向。所以这个系统的本质就是一个**“规则引擎 数据匹配 可视化展示”**的查询系统而不是什么高深的人工智能。搞清楚这一点整个项目的复杂度一下就降下来了——绝大部分工作量在数据清洗和界面交互上而不是算法本身。1.2 用户角色与核心流程设计系统有两种用户考生和家长前台管理员后台。考生的操作流程我设计成了四步注册登录完善个人信息分数、位次、选科、省份系统根据信息自动完成数据匹配生成推荐列表用户可以通过省份、院校类型、专业方向等条件二次筛选点击院校查看近三年录取趋势、专业分数线、选科要求和就业方向。管理员端就简单多了批量导入每年的录取数据、维护院校专业库、管理用户反馈。这四条流程定下来前端路由、后端接口、数据表结构就都有方向了。我不会一上来就写代码而是先画了一张简单的数据流图用户输入 → 后端算法模块 → 数据库查询 → 结果封装 → Vue前端渲染。后续所有开发都围绕这条链路展开。2. 技术选型的幕后逻辑Django还是Flask2.1 后端框架对比与最终决策看到标题里的“django flask”说明很多人在纠结到底用哪个。我把两个框架的对比直接列出来对比维度DjangoFlask生态完整性自带ORM、Admin后台、认证、表单需要自己装扩展学习曲线较陡概念多平缓容易上手适合场景中大型项目后台管理需求多的轻量API服务微服务数据建模models.py声明式迁移方便需配SQLAlchemyAdmin后台一行代码生成后台需要第三方库这个项目里有一个硬性需求管理员要批量管理几千条院校录取数据。Django自带的Admin后台可以直接复用配好模型之后增删改查、批量导入导出、权限控制全都有了——这些功能如果从零写至少要一周工作量。所以我的建议很明确凡是像这样“有数据管理后台需求”的项目闭眼选Django如果只是做一个纯API服务Flask更轻快。另外说一句用Django还有一个隐形好处它的ORM自带了数据库迁移机制我开发中改了三四次表结构都是python manage.py makemigrations一行命令同步省了大量手工改表的时间。这个体验在FlaskSQLAlchemy里虽然也能实现但没这么顺滑。2.2 为什么是Vue PyCharm 全家桶前端选Vue核心原因是组件化和渐进式引入。这个项目最复杂的界面是“院校列表 条件筛选 图表展示”Vue的组件化开发能把“筛选条件栏”、“院校卡片”、“录取位次趋势图”拆成独立组件各管各的状态互不干扰。PyCharm的价值则体现在两个地方一是对Django的“开箱即用”支持——创建项目时直接有Django模板运行配置、模板调试、ORM模型检查都是图形化的二是它的数据库工具很顺手我右键就可以查看数据表记录不用切到Navicat。这里插一句PyCharm的Professional版是商业软件学生可以申请免费授权这也是我推荐学生党优先考虑PyCharm的原因。技术栈最终定为后端Python 3.10 Django 4.x Django REST Framework前端Vue 3 Vite Element Plus Axios ECharts数据库MySQL开发期用SQLite就够了部署换MySQL开发工具PyCharm Professional2.3 解决“选科”这个新高考特有的问题如果只看老高考的“文科/理科”二分法这个系统会非常简单。但新高考改革后大部分省份实行“312”模式选科组合直接决定了你能报哪些专业。比如临床医学通常要求“物理化学”而历史类考生基本与计算机专业无缘。这意味着数据表里必须增加选科要求字段匹配逻辑也不是简单的分数比较。我设计了一个subject_requirement字段存的是类似“物理|化学”的字符串匹配时先拆分再逐一检查考生选科是否覆盖。这块逻辑不复杂但容易漏——遇到个别院校专业“物理或化学任选其一”的情况就得单独处理这个细节我后面在“常见问题”里还会提到。3. 核心算法与数据库设计推荐怎么才算“准”3.1 位次法分数会贬值位次不会志愿填报圈里有一句老话——“看分没意义看位次才靠谱”。为什么因为每年考题难度不同同一所学校的录取分数线会波动但录取考生的省排名位次相对稳定。比如某校去年录取最低分是590今年可能涨到605但对应的位次基本都在全省8000名左右。所以系统的核心算法用的是位次匹配。具体逻辑是这样的用户输入高考分数和全省位次系统用考生位次去比对各院校近三年的最低录取位次计算出一个“位次差”指标——考生位次比院校录取位次高越多录取概率越大根据位次差区间自动归类为“冲、稳、保”三档。我用Django的ORM来实现这个逻辑核心代码如下def match_schools(student_rank, student_subjects, province): # 获取所有院校的最低录取位次 schools AdmissionScore.objects.filter( provinceprovince ).values(school_id, year, min_rank) # min_rank为该年最低录取位次 # 计算近三年平均最低位次 rank_map {} for item in schools: key item[school_id] rank_map.setdefault(key, []).append(item[min_rank]) result [] for school_id, ranks in rank_map.items(): avg_rank sum(ranks) / len(ranks) # 近三年平均最低位次 # 考生位次比平均位次高(数字小)概率大 diff avg_rank - student_rank school School.objects.get(idschool_id) # 选科过滤 if not check_subjects(school.requirement, student_subjects): continue if diff 5000: level 保 elif diff -2000: level 稳 else: level 冲 result.append({ school: school, avg_rank: int(avg_rank), diff: int(diff), level: level, # 历年数据 history: [r for r in ranks] }) result.sort(keylambda x: x[avg_rank]) return result这段代码里有个细节我要说一下diff 5000意味着考生位次比院校平均位次高5000名也就是说考生有足够的余量录取概率很大归为“保”diff -2000时考生虽然比平均位次低一点但在可接受范围内归为“稳”如果比平均位次低超过2000名就属于冲刺了。很多人会问这些阈值是拍脑袋定的吗其实不是这是根据往年经验调出来的。不同省份考生密度不一样5000名在考生大省可能只值几分在考生少的省份可能就是几十分了。所以我把阈值抽成了配置项方便按省份调整# config.py THRESHOLD { rush: -2000, # 低于平均位次这个值以内算冲刺 safe: 5000, # 高于平均位次这个值以上算保底 }这种设计方式值得所有做推荐类项目的人参考核心算法先把“能不能跑通”解决再把“参数可调”跟上不要一上来就追求完美。先用固定规则跑通再根据测试结果慢慢调参这是最务实的做法。3.2 专业推荐不搞“智能”搞“测评 规则”说实话市面上的“智能测性格选专业”多数是噱头但我还是在系统里做了一个简化版专业推荐模块。思路是借用了霍兰德职业兴趣测试的六型分类模型实用型R、研究型I、艺术型A、社会型S、企业型E、常规型C做了一个20道题的简化问卷。用户做完后计算得出自己的主导类型组合。然后我把专业库里的每个专业都打上了类型标签比如“计算机科学与技术”偏研究型I和企业型E“护理学”偏社会型S和实用型R。用户测评完系统按匹配度排序输出推荐专业清单。技术实现上没什么难度就是两张表之间的多对多关联但这里我想强调一个产品逻辑测评只是辅助决策不能代替数据。所以我在前端展示时特意把专业推荐和录取数据推荐放在两个独立模块里一个解决“我喜欢什么”一个解决“我能上什么”最后让用户自己平衡。这个设计在后来的试用反馈里被多次点赞说比那些把“喜欢”和“能上”揉在一起的系统靠谱得多。3.3 数据模型设计六张核心表项目的数据模型我从一开始就定了六张核心表这里直接贴出来# models.py节选 from django.db import models class Province(models.Model): name models.CharField(max_length32, uniqueTrue) gaokao_type models.CharField(max_length16) # 312 / 33 / 文理分科 class School(models.Model): name models.CharField(max_length128) province models.ForeignKey(Province, on_deletemodels.CASCADE) school_type models.CharField(max_length32) # 综合/理工/师范/医药等 is_985 models.BooleanField(defaultFalse) is_211 models.BooleanField(defaultFalse) is_double_first_class models.BooleanField(defaultFalse) subject_requirement models.CharField(max_length64) # 如 物理|化学 class Major(models.Model): name models.CharField(max_length128) code models.CharField(max_length8) category models.CharField(max_length32) # 工学/理学/管理学等 holland_types models.CharField(max_length16) # 如 RI class SchoolMajor(models.Model): school models.ForeignKey(School, on_deletemodels.CASCADE) major models.ForeignKey(Major, on_deletemodels.CASCADE) subject_requirement models.CharField(max_length64, blankTrue) # 一个学校同一个专业在不同省份招生人数不同 plan_count models.IntegerField(default0) class AdmissionScore(models.Model): school models.ForeignKey(School, on_deletemodels.CASCADE) major models.ForeignKey(Major, on_deletemodels.CASCADE, nullTrue, blankTrue) province models.ForeignKey(Province, on_deletemodels.CASCADE) year models.IntegerField() # 2022/2023/2024 min_score models.IntegerField(default0) # 最低分 min_rank models.IntegerField(default0) # 最低位次 avg_score models.FloatField(default0) # 平均分 class UserProfile(models.Model): user models.OneToOneField(auth.User, on_deletemodels.CASCADE) province models.ForeignKey(Province, on_deletemodels.SET_NULL, nullTrue) score models.IntegerField(default0) rank models.IntegerField(default0) subjects models.CharField(max_length32) # 如 物理|化学|生物这里有个设计细节值得展开AdmissionScore表里我存了major外键且允许为空。原因是一个院校的投档线和具体专业的录取线是两回事——有些省份只公布院校最低投档线有些省份会公布到具体专业。字段允许为空的好处是即使全省数据只拿到院校层面的也能正常入库使用以后补录了专业数据也不影响如果一开始就设为非空导入数据时遇到缺失就要做额外处理平白增加工作量。这也是做数据处理项目时的一个通用心得不要把表的严谨性建立在“数据一定完整”的假设上。3.4 近三年位次趋势的核心查询算法里还有一个高频操作查某个学校某专业近三年的录取位次。这个查询在Django ORM里写很简单但有个性能优化点要提醒一下——不要循环里查数据库。我踩过这个坑第一次实现时在match_schools的循环里每个学校各查一次AdmissionScore本地测试几百条数据不觉得慢等导入真实的两千多条数据后接口响应直接飙到十几秒。正确的做法是批量查询把要查的学校ID收进一个列表一次性取出来在内存里分组# 正确姿势 school_ids [s.id for s in schools] all_scores AdmissionScore.objects.filter( school_id__inschool_ids, year__in[2022, 2023, 2024] ).order_by(school_id, year) # 内存中按学校分组 from collections import defaultdict score_map defaultdict(list) for score in all_scores: score_map[score.school_id].append(score)这个改动让接口耗时从十几秒降到几百毫秒量级直接改变。N1查询问题是每个Django API开发者的必修课这个项目就是最好的练手场景。4. 实操落地从工程创建到页面联动4.1 环境准备与Django工程初始化先说环境我用的是PyCharm Anaconda组合。Anaconda的好处是创建虚拟环境方便不污染系统Python。我建议每个项目单独建环境# 创建并激活虚拟环境 conda create -n gaokao python3.10 -y conda activate gaokao # 安装依赖 pip install django djangorestframework mysqlclient celery django-cors-headers pandas openpyxl然后在PyCharm里新建Django项目。这里有个小提示如果你用的是PyCharm Professional直接选Django模板生成会自动配置好settings.py、urls.py和manage.py的结构如果用Community版用命令创建也一样django-admin startproject gaokao_system cd gaokao_system python manage.py startapp api python manage.py startapp users项目结构我分了几个应用appgaokao_system/ ├── gaokao_system/ # 项目配置 ├── api/ # 核心接口院校匹配、专业推荐 ├── users/ # 登录注册、个人资料 ├── data/ # 数据导入与管理 ├── static/ # Vue前端打包后的静态文件 └── templates/ # Vue的index.html入口为什么拆多个app而不是全堆在一个里因为Django的app本质上就是模块边界。志愿匹配和数据导入是两个完全不同的功能域拆开之后代码清晰出了问题也好排查。这不是装模作样的规范是真的能省心。4.2 数据导入Pandas一把梭数据从哪来我的做法是从各省考试院官网和公开数据集里收集CSV/Excel文件然后用Pandas清洗、入库。这里分享一个数据清洗的经典流程# data/import_scores.py import pandas as pd from api.models import School, AdmissionScore, Major df pd.read_excel(sichuan_2024.xlsx) # 1. 去重 df df.drop_duplicates(subset[school_name, major_name, year]) # 2. 处理缺失值位次缺失的按分数降序填充规则处理 df[min_rank] df[min_rank].fillna(0).astype(int) # 3. 清洗专业名称中的空格和特殊字符 df[major_name] df[major_name].str.strip().str.replace(r\s, , regexTrue) # 4. 逐个入库 for _, row in df.iterrows(): school, _ School.objects.get_or_create( namerow[school_name], defaults{...} ) major, _ Major.objects.get_or_create( namerow[major_name], defaults{category: row.get(category, 未知)} ) AdmissionScore.objects.create( schoolschool, majormajor, province_idprovince_id, yearrow[year], min_scorerow[min_score], min_rankrow[min_rank], avg_scorerow.get(avg_score, 0) )这里用get_or_create()而不是先查后建避免了重复ID的坑。而且数据导入是个会反复执行的操作幂等性很重要——你导错了改个数据再跑一遍不应该产生重复记录。4.3 Django REST Framework写推荐接口匹配接口是系统的心脏我用DRF的APIView写逻辑清晰也方便后面加权限控制# api/views.py from rest_framework.views import APIView from rest_framework.response import Response from rest_framework.permissions import IsAuthenticated class RecommendView(APIView): permission_classes [IsAuthenticated] # 需要登录 def post(self, request): user request.user # 优先用请求参数没有则用用户已存的资料 score request.data.get(score, user.userprofile.score) rank request.data.get(rank, user.userprofile.rank) subjects request.data.get(subjects, user.userprofile.subjects) # 解析选科 subject_list subjects.split(|) # 匹配院校 results match_schools(rank, subject_list, user.userprofile.province) return Response({ code: 0, data: { total: len(results), list: results[:50], # 一次最多返回50条 threshold: THRESHOLD, } })接口写好后用PyCharm自带的HTTP Client或者Postman就能直接测试。这里有一个调试习惯想推荐先写死数据测接口再动态传参。我开发时是先在Django shell里把match_schools函数用几组有代表性的分数测一遍比如600分/位次8000、560分/位次12000、500分/位次22000确认匹配结果合理再挂到接口上。这样排查问题时会很容易区分是算法问题还是接口问题。4.4 Vue前端搭建项目与页面路由Vue项目我用Vite脚手架创建npm create vitelatest frontend -- --template vue cd frontend npm install vue-router axios element-plus echarts为什么用Vite不用Vue CLI因为Vite冷启动快依赖预构建也更智能Vue CLI已经处于维护模式新项目没必要再选它。Element Plus是Vue 3配套的组件库搭列表、表单、标签页很快ECharts用来画录取位次趋势图。页面路由设计如下// router/index.js import { createRouter, createWebHistory } from vue-router const routes [ { path: /, redirect: /recommend }, { path: /login, component: () import(../views/LoginView.vue) }, { path: /recommend, component: () import(../views/RecommendView.vue) }, { path: /school/:id, component: () import(../views/SchoolDetailView.vue) }, { path: /major-test, component: () import(../views/MajorTestView.vue) }, { path: /admin, component: () import(../views/AdminView.vue), meta: { admin: true } }, ]这里用到Vue的动态路由——/school/:id这个路由用户点击某个院校卡片后前端根据id参数跳转到详情页详情页再用this.$route.params.id去调后端接口拉取该校近三年录取数据并画ECharts图。这个交互几乎每一个数据列表类项目都会用到值得重点练熟。4.5 前端与后端联调跨域问题一次解决前后端分离开发时Vue跑在localhost:5173Django跑在localhost:8000端口不同浏览器会拦跨域请求。后端装django-cors-headers并配置# settings.py INSTALLED_APPS [ # ... corsheaders, ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, # ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, ]注意CorsMiddleware要放在CommonMiddleware之前不然中间件顺序不对会导致跨域配置不生效。这个坑我栽过后来看日志才发现是顺序问题。前端这边只需要用Axios统一配置baseURL// api.js import axios from axios const request axios.create({ baseURL: http://localhost:8000/api, timeout: 10000 }) // 请求拦截器自动携带token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Token ${token} } return config })Token认证我用的Django REST Framework自带的TokenAuthentication简单可靠。JWT虽然功能更多但对这个量级的项目来说反而显得笨重——Token生效快、调试直观安全性完全够用。4.6 推荐结果的前端展示与动态筛选推荐结果页是用户看得最多的页面我做了“卡片式列表 多条件筛选 分页”三个功能。卡片上显示院校名称、省份、综合标签985/211/双一流、近三年平均最低位次、冲稳保等级等级用不同颜色标签区分——冲是红色、稳是黄色、保是绿色。这个设计符合填报时的心理预期。筛选条件栏包括省份、院校类型、是否有985/211标签、冲稳保等级、专业关键字。核心逻辑用computed属性实现把筛选条件变化映射成列表过滤template div classschool-grid SchoolCard v-forschool in filteredSchools :keyschool.id :schoolschool clickgoDetail(school.id) / /div /template script setup import { ref, computed } from vue import SchoolCard from ../components/SchoolCard.vue const schools ref([]) // 后端返回的原始数据 const filters reactive({ region: , type: , level: , keyword: }) const filteredSchools computed(() { return schools.value.filter(s { if (filters.region s.region ! filters.region) return false if (filters.type s.school_type ! filters.type) return false if (filters.level s.level ! filters.level) return false if (filters.keyword !s.majors.some(m m.includes(filters.keyword))) return false return true }) }) /script用computed而不是methods是因为筛选是纯依赖数据的高频计算computed会缓存结果性能表现更好。这个细节对前端新手来说很实用——什么时候用computed、什么时候用watch是Vue面试最常问的知识点之一。4.7 部署上线从开发环境到服务器开发完成后要部署到服务器我用的是Nginx uWSGI MySQL组合。Django侧的关键步骤# 收集静态文件 python manage.py collectstatic # 安装uwsgi pip install uwsgiuWSGI配置文件[uwsgi] chdir /srv/gaokao_system module gaokao_system.wsgi:application master true processes 4 threads 2 socket 127.0.0.1:8001 vacuum trueNginx负责托管Vue打包后的静态文件和反向代理API请求# nginx.conf server { listen 80; server_name your_domain.com; # Vue前端静态文件 root /srv/gaokao_system/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; # 解决Vue路由刷新404问题 } # API反向代理 location /api/ { proxy_pass http://127.0.0.1:8001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;这行配置是Vue项目部署的精髓——前端路由在刷新时会向服务器发起资源请求如果不回退到index.html就会出现404。所有Vue SPA项目上线时都要检查这一行有没有写对。5. 常见问题与排错实录5.1 N1查询导致接口响应慢前面讲算法优化时提到过N1查询问题这里再展开说。初始版本里match_schools函数每次循环都会去查一次学校详情、一次专业列表导致代码虽然“看起来没问题”实际性能一塌糊涂。排查过程是这样的先在浏览器Network面板里看到接口耗时12.7秒然后用Django的connection.queries打印出SQL语句数量发现一个请求引发了2000多条SQL。这就是典型的循环内查库——每查一条数据发一次数据库请求。解决方案就是前面提到的批量查询把所有学校ID收集起来一次查完再在内存里组装。优化后SQL数量降到个位数接口耗时降到400毫秒。衡量ORM写得好不好的金标准就是看SQL查询次数。5.2 选科匹配边界遇到“或”关系怎么办新高考选科要求里有一种情况特别容易写错专业要求“物理或化学”意思是考生选了其中任何一科就满足条件。如果用我前面那种“集合包含”的简单判断会把这种情况误判为不满足。我加了一个解析函数把要求拆成“必须满足的一组”和“任选其一的一组”def check_subjects(requirement_str, selected_subjects): if not requirement_str: return True selected_set set(selected_subjects) # 按“且”关系拆分 for and_group in requirement_str.split(): group and_group.replace((, ).replace(), ) if | in group: # “或”关系任一满足即可 if not (selected_set set(group.split(|))): return False else: if group not in selected_set: return False return True这个函数属于典型的“看起来简单但容易漏”的逻辑。我的建议是写完立刻用测试用例验证——物理化学生物、物理政治地理、历史生物政治每种组合各跑一遍覆盖住主要情况再继续往下做功能。5.3 Vue打包后路由404部署阶段遇到一个经典问题把npm run build生成的dist目录放到Nginx后首页能打开但一旦刷新/school/102这种详情页就报404。原因我在上文的Nginx配置里已经点到了——单页应用的路由是前端切出来的服务器上并没有对应的/school/102这个物理路径所以Nginx默认会返回404。一个try_files指令解决的location / { try_files $uri $uri/ /index.html; }现在很多新手喜欢用hash模式路由/#/school/102这种方式刷新确实没这个问题但URL里带着#号非常不好看也不利于SEO。我的建议是用history模式Nginx回退配置一步到位。5.4 数据库日期字段的“取年份”陷阱在统计近三年录取趋势时我用Django ORM取年份一开始写的是score.year.year结果发现这是SQLite里DateField的类型转换问题——score.year如果定义成IntegerField就不会有这个问题但如果定义了DateField在SQLite下取年份就要注意处理。我的建议是录取数据里的年份直接用IntegerField这只是一个展示和对比维度没必要用DateField。6. 经验沉淀如果让我重做一遍的改进清单几次测试下来系统基本达到了当初的定位数据准确、推荐有依据、交互顺滑。但站在总结经验的角度有几个地方如果重做一遍我会做得更好。第一数据源的持续性设计应该提前做。每年高考录取数据更新一次靠手工下载Excel再导入不是长久之计。如果正式上线应该做一个爬虫模块定时从省考试院网站抓取数据或者至少做一个“管理员上传Excel后自动增量更新”的功能而不是像现在这样半手动导入。第二推荐结果的解释性可以更强。现在系统只告诉用户“这是稳档”但没有解释为什么——比如可以展示“该校近三年最低位次分别为9000、9500、8800您的位次为8000在过去三年中均高于录取线”这类文本说明让用户信服。我当初因为时间原因没做这个模块但试用的几位朋友都不约而同问过“为什么这个学校是稳的”这让我意识到推荐系统的置信度说明比推荐本身更重要。第三性能优化还可以再进一步。目前match_schools每次请求都对全量院校做计算数据量再大一点就该考虑把“位次匹配”的结果提前算好存入缓存或者用Redis做一层缓存。对于当前几千条数据来说没必要但架构上要留出这个空间。最后一条建议给所有想做类似系统的朋友做这类偏数据展示的系统第一优先级是把主流程跑通而不是追求算法花哨。先用一个最简单的规则匹配做完最核心的查询流程让用户能输入、能看到结果、能筛选就已经是一个完整的MVP了。至于更精准的算法、更智能的推荐那是在PV基础上一步步迭代的事。我在这个项目里最大的感触就是真正消耗时间的不是代码本身而是数据清洗和排错这两件事做得越扎实系统就越经得起用。