每年毕设季我都能在后台收到大量类似的私信“学长Django选题有什么推荐”“Python 毕设做什么题目比较好过”“有没有现成的源码和文档能参考”说实话同一个问题被问了几十次之后我意识到大家真正需要的不是一堆零散的技术教程而是一个完整的、能落地的、从需求到答辩全流程走通的参考项目。今天这篇就来梳理我用 Django 做过的一个完整系统——基于 Python 的考研学习系统从核心模块设计到代码实现再到文档整理和一条龙定制交付尽量把我在实操中踩过的坑和摸出来的门道都写出来。这个项目的业务场景很清晰伴随考研人数逐年上涨考生需要一个能系统管理学习计划、刷题记录、知识点掌握情况和个人笔记的环境。很多现成的 app 功能太杂、广告太多而学校图书馆里又经常需要一套内部可部署的轻量解决方案。于是这个基于 Django 的考研学习系统本质上就是一个带用户认证、题库管理、在线刷题、进度统计和学习笔记的 Web 应用前端用 Bootstrap 模板渲染后端用 Django SQLite/MySQL既能满足功能演示又能支撑论文里的数据流和模块图。适合所有选 Python / Web 方向做毕设的同学参考尤其是想用 Django 但不知道从哪下手的新手。1. 项目拆解一套考研学习系统到底该做什么1.1 用例场景与核心需求分析很多同学拿到题目第一反应是“考研学习系统 刷题网站”这个理解本身没错但如果只做一个刷题模块论文篇幅撑不起来答辩时也容易被老师问倒。我当初做的时候先把用户角色拆成了三类普通考生、系统管理员、访客。普通考生注册登录、修改个人信息、浏览题库、按科目刷题、提交答案、查看得分与错题记录、维护个人学习笔记、查看学习计划与每日进度。系统管理员科目管理、题目批量导入导出、试卷/练习配置、用户管理、学习数据统计。访客仅能浏览公开课程简介和系统说明不能答题和写笔记。这个角色划分直接影响数据库表的设计。我在实际项目中用 Django 自带的User表做认证再通过Profile扩展用户手机号和头像角色判断不是靠建多张用户表而是用一个user_type字段配合装饰器控制视图访问权限这样既能减少表数量又方便后续扩展。1.2 核心功能模块划分与信息架构整个系统的功能可以拆成六大模块用户管理模块、题库管理模块、在线练习模块、考试评估模块、学习计划模块、数据看板模块。每个模块对应四到五张数据库表表之间用外键串起来整体结构是这样的用户管理UserDjango 内置、Profile扩展表、OperationLog操作日志可选。题库管理Subject科目、QuestionBank题目、QuestionOption选项、QuestionType题型字典。在线练习PracticeRecord练习记录、AnswerDetail每道题的作答详情。考试评估ExamPaper试卷、ExamRecord考试记录、ExamScore得分汇总。学习计划StudyPlan计划主表、PlanItem计划明细、DailyCheckIn每日打卡。数据看板不建表直接通过 ORM 聚合查询统计用户数、答题数、正确率、活跃度。这个结构的好处是表与表之间的外键关系非常清晰画 E-R 图时层次分明写论文时也能直接复用这些实体关系描述。很多同学喜欢把所有数据塞到一两张表里答辩时系统功能聊得不错但一画数据库设计图就露馅这恰恰是毕设评审最看重的一环。1.3 为什么选 Django 而非 Flask / FastAPI这是个老生常谈的问题但对毕设项目来说答案其实非常明确Django 自带后台管理系统、ORM、表单校验、登录认证和 Session 机制这些功能如果换成 Flask 都要自己装第三方库或手写实现。哪怕只是做一个几千行代码的毕设项目用 Django 也能省掉至少三分之一的工作量。我对比过同样功能用 Flask 和 Django 实现的差异Flask 灵活但也意味着你需要自己决定用什么扩展一旦扩展之间版本冲突新手排查起来非常痛苦FastAPI 性能好但异步特性和 Pydantic 模型对刚接触 Python 的同学不太友好Django 则把常规 Web 开发的标准答案都摆在你面前路由、模板、ORM、Admin 一应俱全配上详细的中文文档出问题的概率最低。2. 数据库设计与系统架构实战2.1 选题表结构设计中的关键决策我先从题目表说起因为这是整个系统的核心。题目表字段我建议这样设计class QuestionBank(models.Model): subject models.ForeignKey(Subject, on_deletemodels.CASCADE, verbose_name所属科目) question_type models.IntegerField(choices((1, 单选题), (2, 多选题), (3, 判断题)), verbose_name题型) content models.TextField(verbose_name题干) analysis models.TextField(blankTrue, verbose_name答案解析) difficulty models.IntegerField(default3, verbose_name难度等级(1-5)) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: verbose_name 题目 verbose_name_plural verbose_name请注意我这里没有把选项直接放到题目表里而是单独拆了一张QuestionOption表原因有三个第一多选题和单选题的选项数量不固定放主表会产生大量空字段第二选项单独成表后可以直接用外键关联排序、修改、统计都方便第三这是数据库第二范式的标准做法写论文时能体现你懂规范化设计。类似的还有AnswerDetail表用question和practice_record两个外键做联合约束保证同一个学习记录里不会出现重复作答。2.2 Django ORM 查询优化的几个必踩点系统跑起来容易但数据量一上来很多同学就发现页面加载变慢了。原因基本都出在 ORM 查询上最典型的场景是展示练习记录列表时你需要同时拿到记录关联的题目内容、题目所属科目和用户昵称。如果直接用外键属性逐条取会触发 N1 查询。我在代码里做了两处处理效果立竿见影# 主动使用 select_related 预取外键关联对象 records PracticeRecord.objects.select_related(user, question__subject).filter(userrequest.user) # 列表页需要统计正确率时使用 values annotate 一次性聚合 summary (AnswerDetail.objects .values(is_correct) .annotate(totalCount(id)) .order_by())另外还有一个很容易被忽视的点Django 的QuerySet是惰性的很多同学在视图里反复filter同一张表以为只执行了一次查询实际每次filter都会产生新的 SQL。正确做法是先写好一个基础查询集然后一次把它消费掉。类似list()这种强求值操作在数据量不大时无所谓但到了优化答辩环节这些细节都能成为你的加分项。2.3 安全机制与权限控制落地方案考研系统面向校园内网但该做的安全校验一样都不能少。Django 默认带了 CSRF 防护、XSS 过滤和 SQL 注入防护前提是你别乱关中间件。我在视图层用login_required装饰器做登录控制用自定义装饰器做角色判断from django.contrib.auth.decorators import login_required from django.core.exceptions import PermissionDenied def admin_required(view_func): login_required def _wrapped_view(request, *args, **kwargs): if request.user.user_type ! 1: raise PermissionDenied return view_func(request, *args, **kwargs) return _wrapped_viewSession 设置上建议开启 Django Session 的过期时间限制比如两小时无操作强制重新登录。对于密码修改直接在UserAdmin里反向注册即可不用单独写视图。这些操作看起来基础但很多毕设项目的安全隐患排查表里漏写 Session 固定防护和密码明文存储是经常被评委追问的硬伤。3. 核心功能实现与代码讲解3.1 用户认证与会话机制的重要细节登录和注册是必做模块但细节决定成败。我在注册时用UserCreationForm做用户名唯一性校验密码自动加密存储登录之后用 Django 的login()方法将用户 ID 写入 Session。有一个坑Django 默认的登录视图会把重定向逻辑写在next参数里但我发现很多人直接忽略了这个参数导致用户登录后总是跳回首页。改进做法是if request.method POST: username request.POST.get(username) password request.POST.get(password) user authenticate(request, usernameusername, passwordpassword) if user: login(request, user) next_url request.POST.get(next) or reverse(index) return redirect(next_url)至于记忆登录状态我建议别碰“记住我”的自定义 Cookie 逻辑直接用 Django 的SESSION_EXPIRE_AT_BROWSER_CLOSE设置就够了否则很容易把 Session 生命周期搞乱。还有一点如果你要在 Cookie 里存放用户 token 做自动登录比如移动端接口请务必给 token 设置过期时间并且不要放敏感字段我用itsdangerous生成签名 token 后在前端请求头携带后端用同样密钥解码整体流程既安全又好解释。3.2 题库与作答逻辑的代码实现作答逻辑是本系统最讲究的部分。我最初把判分逻辑写在了前端 JavaScript 里后来发现用户可以直接改 DOM 伪造答案于是立刻改成“题目显示在页面答案提交后由后端统一判分”。具体流程是这样的def submit_answer(request, question_id): if request.method POST: selected request.POST.getlist(answer) # 前端传来选项 ID 列表 question QuestionBank.objects.select_related(subject).get(pkquestion_id) correct_options set(QuestionOption.objects.filter( questionquestion, is_correctTrue ).values_list(id, flatTrue)) is_correct set(map(int, selected)) correct_options AnswerDetail.objects.create( userrequest.user, questionquestion, selected_optionsjson.dumps(selected), is_correctis_correct ) return JsonResponse({is_correct: is_correct, analysis: question.analysis})这里有两个细节值得展开。第一多选判分不是简单地比字符串而是把选项 ID 列表转成set之后再比较这样顺序不同也能正确判分。第二用json.dumps把用户答案存成 JSON 字符串方便后续在错题本里原样回显作答内容同时也不影响数据库的简洁性。练习记录的幂等性也很重要连续点击提交按钮会造成一条题目产生多条作答记录。我的处理方式是给PracticeRecord和Question加UniqueConstraint联合唯一约束数据库层直接拦截重复插入代码层再配一个“提交后按钮置灰”的小脚本双保险。3.3 学习计划模块的定时与进度算法学习计划模块如果不做定时提醒很容易沦为纯粹的“打卡软件”。Django 本身没有内置任务队列为了实现每天定时更新学习状态我用了最简单可靠的方案——Django 管理命令配合系统 crontabclass Command(BaseCommand): help 每天凌晨自动生成当天的学习计划条目 def handle(self, *args, **options): today timezone.localtime(timezone.now()).date() plans StudyPlan.objects.filter(is_activeTrue) for plan in plans: PlanItem.objects.get_or_create(planplan, datetoday) self.stdout.write(self.style.SUCCESS(计划条目生成完毕))在 Windows 部署演示环境时没有 cron我就换成APScheduler实现一个后台定时线程效果等价。学习计划完成率的计算用了“已完成明细数 / 全部明细数”的简单公式但要注意卡片上展示的进度条颜色变化逻辑完成率低于 30% 显示灰色30%-70% 显示黄色超过 70% 显示绿色这样视觉反馈更直观演示截图也更好看。3.4 数据看板与可视化统计分析论文里“数据统计模块”如果只有表格就太单薄了我用highcharts和纯 JavaScript 画了两个关键图表近 7 天刷题量柱状图和各科目正确率饼状图。数据来源就是 ORM 聚合结果from django.db.models import Count, Avg from django.db.models.functions import TruncDate records_trend (AnswerDetail.objects .filter(userrequest.user, created_at__gtetimezone.now() - timedelta(days7)) .annotate(dayTruncDate(created_at)) .values(day) .annotate(countCount(id)) .order_by(day))这个查询用到了TruncDate它能自动把datetime转成日期并按天分组比自己在 Python 里按天遍历再统计要优雅得多。图表数据接口建议返回 JSON 数组前端只需要塞进Highcharts.setOptions里即可。4. 毕设文档与一条龙定制全流程4.1 论文/设计文档怎么写才能不被质疑程序写完了论文才是真正决定成绩的一环。我的文档结构是经典五章绪论研究背景与意义、国内外现状、核心技术介绍Python、Django、MySQL、Bootstrap、系统分析可行性分析、功能需求分析、用例图、系统设计总体架构、模块设计、数据库设计、系统实现核心页面展示、关键代码段说明、测试用例。这个结构是经过多年带毕设验证过的“安全模板”不容易出问题。值得特别提醒的是数据库设计部分一定要把 E-R 图和数据字典表写全。我在数据字典里列出了每张表的字段名、类型、长度、约束、是否主键外键、备注说明这部分内容最占篇幅但同时又是很多同学最容易偷懒的地方。只要这块写扎实答辩时老师问到任何一张表你都能从容说出设计意图。4.2 代码讲解与一条龙定制的注意事项标题里的“代码讲解”其实就是答辩准备的代名词。我的建议是不要试图把每一行代码都背下来而是准备三条主线项目的运行流程从启动服务到用户浏览器发送请求再到数据库查询、核心模块的实现逻辑可以手画一张请求流程图、以及你遇到的问题和解决方案。答辩老师问得最多的是“为什么这么设计”而不是“这句代码什么意思”。“一条龙定制”通常指的是环境搭建、数据库初始化、本地运行指导、论文排版协助、查重修改建议这些服务。实际操作中最大的坑是环境不一致很多同学在自己电脑用 Python 3.12 Django 4.2 跑通了到学校机房却因为 Python 版本过低直接报语法错误。我后来统一要求项目锁死requirements.txt版本并配套写一份README从 Python 安装开始一步步写清楚减少大量沟通成本。4.3 部署与演示环节的关键准备线上部署不是必选项但一个能在线访问的 Demo 绝对是答辩加分项。我之前用django-compressor压缩静态资源再配合WhiteNoise中间件在轻量服务器上做演示非常稳。尤其要注意settings.py里的DEBUG必须改为FalseALLOWED_HOSTS必须配置域名或 IP不然只能本地访问。如果只是为了答辩现场演示我强烈建议准备一套预置好的演示账号里面提前放好了测试数据——比如 500 道题库、10 个学习计划、一周的打卡记录。答辩时你只需要登录后展示“看这个用户已经有 38 道错题正确率 72%”远比现场临时造数据来得从容。5. 常见问题与排查技巧实录5.1 高频报错与解决方案速查表现象排查思路解决方案ModuleNotFoundError: No module named django当前解释器是否指向正确虚拟环境激活虚拟环境检查pip list页面样式丢失静态文件路径错误或DEBUGFalse后未配置静态服务检查STATICFILES_DIRS临时打开DEBUG对比CSRF verification failed表单缺少{% csrf_token %}表单内加入模板标签或ensure_csrf_cookie数据库迁移失败字段类型冲突旧表结构与新模型不一致删掉迁移记录文件后重新makemigrations migrate中文乱码数据库编码不是 utf8mb4创建数据库时指定字符集CREATE DATABASE ... CHARACTER SET utf8mb4登录后刷新即失效Session 后端未正确配置数据库表检查INSTALLED_APPS含django.contrib.sessions执行migrate5.2 数据库并发写引发的数据不一致在线练习模块上线后我曾收到反馈说用户明明提交了正确答案后台统计却显示错误。后来排查发现是两个请求并发写入了AnswerDetail后写入的覆盖了先写入的判断结果。解决方法是把判分逻辑从“先读-再比-后写”改成“数据库唯一约束 条件更新”的方式同时对用户点击行为做了防抖处理。这个案例非常适合写进论文的“测试与调试”章节能体现你不仅会写代码还会排查真实环境问题。5.3 批量删除与级联删除的坑Django 的 ORM 删除操作绝对是一个经典误区。默认的Model.delete()会逐条删除并触发每个对象的delete()方法而QuerySet.delete()是批量 SQL 删除不会执行模型的delete()。如果你在模型里重写了delete()方法做日志记录批量删除就不会生效。我在系统里给题库删题加了保护逻辑题目下如果已经有作答记录则禁止直接删除改用“下架”字段标记。这样既保护了历史数据完整性也避免了误删。一些更实际的经验写到这里系统的技术脉络已经完整了。个人操作下来最大的体会是毕设项目的成功与否不完全取决于技术栈多新而取决于你有没有把所有环节形成闭环需求服务到数据库设计代码实现到文档写作本地调试到现场演示每一步之间都要能互相解释。我带过的很多同学都卡在“代码能跑就躺平”结果答辩时连“为什么这样建表”都回答不上来。代码跑起来只是开始真正能让你安心走上答辩场的是背后的设计与思考。如果你也打算用 Django 做类似选题最后再分享一个很实用的小技巧提前开发通用后台。Django Admin 不只是摆设给所有核心模型注册进去之后管理员修改题目、查看用户记录、导出练习数据都会变得非常方便而且截图还能直接放到论文的“系统管理功能”章节。这几乎是最不费力气却能显著提升系统完成度的选择了。