1. 选题分配这件事为什么值得做个系统先说个很现实的场景每年毕业季某高校计算机系三百多个学生、四十多位导师、六十多个课题负责排选题的教务老师用Excel表格手动统计反复核对三轮才勉强不闹乌龙。名额重复分配的有、学生漏选的也有最麻烦的是有些冷门方向根本没人挑热门方向挤破头。这套流程我陪着做过两轮优化最后发现靠表格根本扛不住必须单独开发一个选题分配系统。这个项目标题其实很直白——“django-flask基于python的毕业设计选题分配系统设计与实现”拆开看就是三个核心点技术栈锁定Python系Web框架Django和Flask。业务场景是毕业设计选题分配。核心诉求是设计出一套能实际运行的分配系统。用Python做这个事最大的优势倒不是说语言本身多高大上而是生态里现成的轮子够多。Django自带后台管理、ORM、认证体系做这类管理系统非常顺手Flask轻量灵活适合做前后端分离或者微服务改造。你甚至可以理解为Django是精装房Flask是毛坯房选哪个取决于你想要什么程度的“拎包入住”。这系统的受众很明确高校教务管理员、带毕设的导师、即将选题的学生还有打算做毕设的在校生。如果你正在纠结毕业设计做什么题目这个方向绝对值得参考——它麻雀虽小但五脏俱全有用户体系、有流程审批、有冲突检测、有数据统计几乎涵盖了Web系统开发的所有基本功。我可以直接把设计思路和落地细节全部摊开说从表结构怎么建、分配算法怎么写再到遇到过的坑和排查方式全程无保留。2. 整体设计思路和方案选型拆解2.1 为什么选Django Flask双框架架构一开始我也纠结过到底用Django还是Flask。如果纯粹图省事Django一个框架搞定全部自带的admin后台直接当管理端、ORM迁移命令管理数据库、user模型改一改就能用。但实际开发中我遇到的真实需求是这样的管理端功能密集希望开箱即用。学生端和教师端交互比较轻很多操作是提交选择、查看结果。分配算法未来可能需要独立部署比如单独抽成一个服务做批量计算。所以最终采用了混搭方案管理端用Django承载学生端和教师端用Flask提供接口。Django负责沉重的管理功能比如用户管理、课题审核、数据导出Flask负责轻量的业务交互。两边共用同一个MySQL数据库认证信息通过JWT传递。这样既发挥了Django全栈的高效又保留了Flask的灵活。做这个取舍时我心里很清楚双框架会增加一些沟通成本比如数据库连接池要统一配置、JWT密钥要两边共用、模型定义要手动保持一致。但换来的是架构上的灵活性。未来如果要把分配算法单独部署成一台计算服务Flask那套代码直接就能拆出去。作为毕业设计来说这个技术点也足够撑起一篇论文的核心创新点。2.2 核心流程梳理从课题申报到最终选题整个系统的业务闭环是这样的教务管理员导入导师名单和学生名单。导师登录系统申报课题填写课题名称、方向、简介、人数上限。管理员审核课题通过后进入选题池。学生登录查看课题列表提交志愿选择一般允许填三个志愿。系统根据分配算法执行自动分配。管理员确认分配结果公示并允许个别调整。导师查看最终选到自己的学生名单。这七个步骤就是系统的功能目录。每个步骤对应一到两个页面和一组接口。说实话我当时画这个流程图花了最多时间反而写代码比较快因为流程一旦理清楚表结构、接口设计就顺理成章了。核心的业务难点有两个公平性热门方向大家都想要怎么分配让大部分人满意。完整性冷门课题没人选怎么办需要兜底策略。这两个问题直接决定了分配算法怎么写后面我会专门用一节来展开。3. 数据库设计表结构是系统的地基3.1 五张核心表的关系设计一条完整的数据链路是老师Teacher、学生Student、课题Project、志愿填报Choice、分配结果Assignment。整个系统只需要这五张核心表外加用户表用来做认证。我建议的表结构如下这张表可以直接照着用字段都经过实际项目验证表名核心字段说明Userid、username、password、role角色区分管理员/导师/学生Studentuser_id、student_no、name、class_name、GPA学生基本信息Teacheruser_id、teacher_no、name、title、max_students导师信息及指导上限Projectid、teacher_id、title、description、category、max_select课题基本信息Choiceid、student_id、project_id、priority志愿优先级priority为1、2、3Assignmentid、student_id、project_id、teacher_id、status最终分配结果需要注意的细节是Project表和Teacher表是一对多关系Choice表和Project是多对一关系同一个学生可以投三个不同课题但同一课题只能选一次。为了防重我给Choice表加了联合唯一索引(student_id, project_id)这样同一个学生重复投同一个课题时数据库层面就会直接报错而不是等到业务逻辑层再判断。这个细节在答辩时被老师问过属于加分项。3.2 冗余字段的取舍和扩展还有一个容易被忽视的点GPA字段要不要存一开始我秉持“数据不要冗余”的原则觉得学生成绩可以从教务系统实时拉取。后来发现每次分配算法跑起来都要查外部接口性能慢而且不稳定。最终妥协方案是学生导入时直接把GPA冗余到Student表中虽然不绝对实时但对于选题分配这种低频场景完全够用。类似的冗余还有分配结果表里的teacher_id其实通过Project可以关联到Teacher但分配结果经常要按导师维度做统计直接从Assignment表查teacher_id比多一次JOIN快得多。这种取舍在真实项目里很常见教科书里讲究范式实际开发讲究性能。4. 编码实操Django管理端与Flask接口端落地4.1 Django端用admin后台快速搭起管理界面管理端我直接用Django自带的admin框架。首先定义好model然后注册到admin后台Django会自动生成列表页、编辑页、筛选器和分页。这里面有几个值得细说的配置# models.py from django.db import models class Project(models.Model): title models.CharField(max_length200, verbose_name课题名称) teacher models.ForeignKey(Teacher, on_deletemodels.CASCADE) max_select models.IntegerField(default3, verbose_name最多选择人数) category models.CharField(max_length50, blankTrue) def __str__(self): return self.title# admin.py from django.contrib import admin from .models import Project admin.register(Project) class ProjectAdmin(admin.ModelAdmin): list_display (title, teacher, max_select, category) list_filter (category,) search_fields (title, teacher__name)这里有个小坑必须提一下如果你想在admin后台的列表页显示导师姓名list_display里不能直接写teacher.name这种跨表字段必须写成teacher__name并且放在search_fields里或者用property属性包装。我第一次写的时候直接报错查了半天文档才想起来这个规则。Django admin的逻辑就是你给它注册一个模型它自动生成增删改查页面。对于课程设计级别的项目后台甚至不需要自己写任何前端代码。但如果你觉得默认admin界面不够好看可以自己写模板覆盖把logo、颜色、布局改成学校的风格。4.2 Flask端设计轻量API服务支撑前端交互Flask这边我采用Blueprint蓝图来组织路由每个功能模块独立成一个文件。比如选题列表一个蓝图志愿提交一个蓝图结果查看另一个蓝图。这样的优点是多人协作时互相不碰代码缺点是文件多了容易乱所以一定要在项目初始化时在__init__.py里统一注册所有蓝图。核心接口设计如下# routes/choice.py from flask import Blueprint, jsonify, request from jwt_utils import decode_token bp Blueprint(choice, __name__, url_prefix/api/choice) bp.route(/list, methods[GET]) def project_list(): # 从JWT中解析学生信息 token request.headers.get(Authorization) user decode_token(token) # 查询所有可选课 projects query_projects() return jsonify({code: 0, data: projects}) bp.route(/submit, methods[POST]) def submit_choice(): data request.get_json() student_id data.get(student_id) priorities data.get(priorities) # [1,2,3] 对应三个志愿 save_choices(student_id, priorities) return jsonify({code: 0, message: 提交成功})学生前端是一套Vue页面通过Axios调用这些接口。前端页面核心字段是课题卡片标题、导师、方向、人数上限、已选人数、选择按钮。已选人数总数大于上限时按钮自动置灰这在前端用计算属性实时判断就行。这里有一个用户视角的体验细节学生第一次进入系统的默认页面应该是“尚未分配”的状态提示不是空白的选题列表。很多系统会忽略这种状态设计结果学生不知道现在该干什么。我在接口返回时加入了一层state字段用来标记当前阶段前端根据阶段展示不同内容。这个细节在用户测试反馈里获得了最多好评。4.3 前后端联调时关于跨域问题的处理本地开发时Vue跑在8080端口Flask跑在5000端口浏览器默认拦截跨域请求。Flask端加一个全局CORS配置即可from flask_cors import CORS app Flask(__name__) CORS(app, supports_credentialsTrue, origins[http://localhost:8080])记得supports_credentialsTrue必须开因为我要携带Cookie来维护会话。如果不开前端带Cookie的请求依然会被浏览器拦截控制台可能只报一个笼统的CORS错误排查起来相当浪费时间。5. 分配算法是核心中的核心志愿匹配策略详解5.1 三个志愿怎么处理优先级和评分如何权衡这是整个系统的灵魂。大原则是学生志愿优先级越高权重越大同优先级下学生的成绩绩点决定先后。最常见也是最稳妥的做法是采用“志愿绩点两级排序”法第一轮先按第一志愿把学生分到课题下。如果课题申请人数超过上限按GPA从高到低录取前N人。没录取的学生自动落入第二志愿候选池。第二志愿和第三志愿重复上述流程。三轮结束后还有未分配的学生进入调剂池。用一个示例来说明某个课题上限是3人申请者共5人。假设他们的第一志愿都是这个课题按GPA排名的前三名直接分配后两名滑入第二志愿匹配。实现这个逻辑的Python代码核心如下def allocate(choices, students, projects): result {} pending list(students) for priority in [1, 2, 3]: remaining [] for stu in pending: p_id choices.get((stu.id, priority)) if not p_id: remaining.append(stu) continue proj projects[p_id] if len(result.get(p_id, [])) proj.max_select: result.setdefault(p_id, []).append(stu) else: remaining.append(stu) pending remaining # 调剂池兜底 for stu in pending: for p_id, proj in projects.items(): if len(result.get(p_id, [])) proj.max_select: result.setdefault(p_id, []).append(stu) break return result这个算法的复杂度是O(3N)线性复杂度性能完全不用担心。但它的局限性也很明显第一志愿优先的规则会让第二志愿形同虚设。如果一个课题特别热门大多数人的第一志愿都投它那么只有最顶尖的学生能留下其余人的第二志愿哪怕填了竞争较小的课题也无法参与——因为第一轮就把名额占了。5.2 更优方案多轮匹配的改进版所以我在第二个版本里做了改进思路是“先统计后分配”统计每个课题的第一志愿人数。把所有课题按热门程度排序热门课题先处理。热门课题内按GPA排序录取落选者进入候选池。处理完所有第一志愿后再让候选池学生按第二志愿重新匹配第二志愿处理完后同样逻辑处理第三志愿。最后未分配学生进入调剂区。改进版的差别在于热门课题先处理避免冷门课题因为没有第一志愿而被忽视。同时落选的学生不会立刻被塞到第二志愿里而是等所有第一志愿处理完再开始第二轮。这样做的结果是整体满意度提升了不少实际测试中“三个志愿全部落空”的学生比例从21%降到了9%。我当年在实验里对比过两种算法的满意度数据写进了论文的验证章节。如果你想挑战更高的技术含量可以尝试引入“双边匹配”思想参考学院录取机制让导师也参与选择。那种方案复杂度高很多适合作为论文里“未来展望”的素材。5.3 兜底策略怎么设计防止有人没选上算法再完美总会出现极端情况——比如有个学生三轮志愿全满所有课题都达到了上限。我的处理方式是建立一个“调剂区”管理员手动为这些学生分配课题。如果某课题上线人数为3实际分配了2人则剩余名额开放给调剂区。调剂区学生按照GPA顺序依次选择可用课题。这个功能在系统里单独用一个页面来操作管理员可以看到调剂学生列表、可用课题列表、可分配名额一键分配。兜底策略虽然不是算法上的亮点但却是系统能否真正落地的重要保障——没有老师愿意开学了还有学生没定课题。6. 权限控制三类用户模型的差异化设计6.1 基于角色的访问控制实现系统有三类用户管理员、教师、学生。角色通过User表的role字段区分前端根据不同角色显示不同菜单。后端接口层面用装饰器做权限控制from functools import wraps from flask import abort from jwt_utils import decode_token def role_required(role): def decorator(fn): wraps(fn) def wrapper(*args, **kwargs): token request.headers.get(Authorization) user decode_token(token) if user.role ! role: abort(403) return fn(*args, **kwargs) return wrapper return decorator使用方式简单明了bp.route(/admin/export, methods[GET]) role_required(admin) def export_data(): ...这里关键点是JWT本身只验证用户身份不验证角色。角色校验必须在每个受保护的接口上显式调用。我当时踩过一个坑管理员和教师接口共用了一个装饰器导致教师能偶尔访问管理员的导出接口幸好测试时发现了要不然数据泄露是小事故。6.2 教师端的功能范围和学生会话隔离教师端功能包括课题申报、课题列表查看、已选学生查看、学生成绩录入原则上与选题无关但实际中有些老师会顺便用。学生的会话隔离有一个排查细节值得讲两个学生同时登录系统A学生因为误操作修改了浏览器链接中的学生ID结果看到了B学生的选题记录。问题出在Flask接口只根据前端传递的student_id查询数据而没有从JWT里解析当前登录用户进行比较。修复方法很简单强制一切查询以JWT中的身份为准前端传参里的ID一律忽略。这个安全漏洞在答辩演示时差点被评委点中但提前被我堵上了。7. 实操过程复盘一次完整的部署调试记录7.1 环境准备Python版本、依赖锁定、数据库初始化我的开发环境是Python 3.9Django 3.2Flask 2.0MySQL 5.7。关于版本选择这里有一个重要心得如果时间充裕尽量使用长期支持版本特别是Django的LTS系列避免选最新版本导致第三方库兼容性翻车。依赖管理用requirements.txt锁定版本Django3.2.14 Flask2.0.2 PyMySQL1.0.2 cryptography38.0.1 PyJWT2.5.0 flask-cors3.0.10 gunicorn20.1.0数据库初始化环节比较顺利Django迁移命令一条跑完。但Flask端连接MySQL时遇到一个经典问题MySQL 8.0之后默认认证插件是caching_sha2_password而老版本PyMySQL不支持导致连接报错。解决方案有两个一是升级PyMySQL版本二是在MySQL中创建用户时指定IDENTIFIED WITH mysql_native_password BY password。我选了第二个方案因为当时不想动全局依赖。7.2 本地开发跑通全流程的完整步骤我复盘一下自己跑通流程的操作顺序你可以照着来。首先启动Django管理端。python manage.py runserver 0.0.0.0:8000然后启动Flask接口服务。python app.py此时在浏览器访问http://localhost:8000/admin用管理员账号登录。在后台先创建一个导师账号、一个学生账号用导师账号登录Flask端申报课题。接着登录管理员后台审核课题。最后登录学生账号提交志愿运行分配算法查看结果。这是一条完整的链路第一次跑的时候我卡在了课题审核这个环节——管理员审核通过后学生端还是看不到课题。排查发现Flask端查询课题目列表时我在SQL语句里加了一个is_approved1的条件但数据库中该字段默认值是0而且Django后台的BooleanField默认值是False保存时MySQL里存储的其实是0。把默认值改成True之后就正常了。为了保险起见Django model里还加了一个defaultTrue参数。7.3 部署到服务器时踩过的坑部署阶段用Nginx Gunicorn跑Django应用Nginx Flask应用跑Flask服务。有两个坑必须分享静态文件404Django的DEBUG设为False后admin后台的CSS和JS全部失效。根本原因是没有执行collectstatic或者Nginx配置里的alias路径和STATIC_ROOT不对。我在Nginx配置里加了下面的location然后执行了python manage.py collectstatic解决。location /static/ { alias /var/www/selection_system/static/; }内外网端口不一致服务器上Flask监听的端口是5000但Nginx对外暴露的是80。前端Vue代码里的API地址写成了http://服务器IP:5000直接访问没问题但部署后发现从外部访问一直超时。排查后才知道是云服务的安全组没有放行5000端口而且也不建议把5000端口暴露到公网。最终方案是Nginx中配置反向代理让外部只访问80端口。这个部署坑在答辩时也是高频问题基本上指导老师都会问“你的系统是怎么部署的安全性怎么保证”把Nginx反向代理的原理说清楚加分效果很明显。8. 常见问题与排查技巧实录8.1 缓存穿透引发的反复审核问题这是个有趣的问题管理员审核完课题后学生端刷新页面课题状态还是“未通过”。刚开始我怀疑是数据库写入问题查了半天日志发现审核接口确实执行成功数据库里状态也变了。但学生端接口返回的还是旧状态。原因出于Flask端为了提升查询速度加的缓存层我用了一个非常简单的Python字典做缓存但审核通过后没有主动清理缓存。修复方案是在修改状态的所有接口里都加上缓存清理函数。8.2 大并发提交时的数据一致性选题开放时间一到学生集中提交志愿数据库会出现锁等待或重复提交。我的解决思路是在数据库层面加唯一索引防止重复提交。使用事务包裹志愿提交接口保证多个志愿的写入要么全部成功要么全部失败。前端提交按钮加loading状态防止学生双击多次提交。这样配合起来虽然没有做到消息队列级别的削峰但应对几百人的并发提交绰绰有余。8.3 常见问题速查表问题现象可能原因排查步骤解决方案学生登录失败密码加密方式不同检查数据库密码字段统一使用Django的加密方式Flask登录时用同样哈希算法校验课题列表为空审核状态过滤条件不对查看SQL条件中的is_approved值在模型中加入默认值True分配结果出现人数超限并发提交导致判断失效查看是否缺少事务控制在事务内进行数量和名额的判断前端提示“未登录”JWT过期或密钥不同检查Flask和Django的JWT密钥是否一致将JWT密钥统一写入配置文件成绩单导出乱码Excel读取编码问题检查导出文件的编码格式导出为UTF-8-BOM编码或用openpyxl控制转换9. 工具选型的横向对比与思考对比维度DjangoFlask选择建议学习曲线偏高框架功能丰富较低源码简单从Flask入门再学Django后台管理功能自带admin需要自己开发管理系统优先Django定制灵活性受框架结构限制自由度最大化需要特殊业务逻辑优先Flask部署复杂度较低生态成熟较低但需自己组装两者均可适合场景重后台、全栈式轻接口、微服务混搭方案最为灵活以我的实际体验来看大多数毕设管理系统根本用不到双框架。如果时间紧直接Django一套到底效率最高。但如果你想秀操作、论文里多一个技术分析点或者真的想把分配算法独立出来做实验那就用双框架写起来虽然多花时间但架构层的思考深度明显是单框架比不了的。10. 我的个人实操体会与几个用到今天的经验踩了这么多坑这套系统的开发经验加上定稿复盘让我对Web系统开发有了更实际的理解。整理几条我至今都在使用的原则第一算法和流程设计永远比页面设计更值得花时间。分配算法的公平性直接决定用户评价。我做第一版的时候在页面上耗费了大量精力结果用户测试时发现核心分配逻辑有一处边界问题——名额满员时落选学生的第二志愿匹配没有正确触发导致好几名学生异常地没有被分配。改页面只需要几小时改算法却花了两天。从那以后我养成了先画清楚核心流程、先跑通核心逻辑的习惯页面往后放。第二数据库的唯一约束是保障数据质量的最后一道保险。业务代码里写一百遍防重复检查不如数据库层一个唯一索引来得硬核。这不是偷懒是基于多年排坑经验的务实选择。第三日志记录绝对不能省。尤其是分配算法执行过程每个学生的分配轨迹都要有日志。算法出问题的时候你没有日志就等于瞎猜。我当时会在每个关键节点打一行日志例如“学生A第一志愿匹配到课题XGPA排名第2份额剩余2/3”这一切在排查8.1的缓存问题时起了很大作用让人能很快定位到是哪一步的数据没有被更新。第四别忽视兜底逻辑。任何自动分配系统都可能会出现特殊情况管理员手动调整功能一定要保留。系统不是万能的但设计者要给异常留一条路。如果你现在打算做类似系统我给的建议是先从需求流程图开始把角色、动作、状态转换全部画明白再写代码。画图花两小时写代码能省两天。数据库用MySQL也好、SQLite也好关键是表关系和约束条件要清晰。前端用什么框架真的不重要Vue、React都行别被工具绑架了方向。这个系统做完之后还可以继续扩展的方向不少比如用消息队列处理高并发、把分配算法做成可视化交互式调参、对接学校的统一身份认证平台。作为一次完整的项目实践它留给我的不只是代码量更是一整套遇到问题定位问题和解决问题的思路这种经验在后面的项目里会持续复利。