简介一套完整的计算机专业毕业设计项目方案基于 Python 与 Django 构建公务员考试信息管理系统包含论文、源代码和说明文档覆盖职位查询、个性化推荐、在线报名、考试提醒与数据分析等核心功能。压缩包共739个文件大小约19.83MB主要包含 Vue 前端组件、Python 后端代码、JS/CSS 页面、SQL 数据库脚本和 docx 论文文档结构清晰便于定位。系统采用前后端分离思路后端基于 Django数据库选用 MySQL前端以 Vue 和 HTML/CSS/JavaScript 为主信息查询、职位推荐、在线报名、考试提醒、数据分析等模块完整能支撑毕业设计展示与功能扩展。源码带有较详细注释说明文档对功能模块、部署流程和数据库设计作出梳理可支撑毕业设计调试、论文撰写或二次开发扩展。目前已有143人学习相关目录和模块结构完整适合课程设计、毕业设计或公务员考试信息管理方向的实战参考。1. 用 Python 做公务员考试信息管理系统难度刚好处在“能独立完成”这一档如果把“公务员考试信息管理系统”拆成业务线并不长招考单位发布公告和职位表考生注册后查看信息并在线报名管理员逐条做资格审核笔试面试结束之后录入成绩系统按排名生成公示名单。你把这个流程做成一个可演示的项目就同时覆盖了两个角色、一组带状态流转的报名单、至少一个数据汇总场景恰好踩中毕业设计评分表里“工作量、数据库设计、文档完整度”这三块。选 Python 的价值不在语言本身而在框架生态。用 Django 这类框架admin 后台、登录认证、ORM 全是现成的代码量能压到 3000 行以内论文里也好交代——哪部分是框架复用哪部分是业务扩展一句话就能说明白。下面沿着一个真实项目的迭代顺序走先定技术选型和数据模型再把报名、审核、成绩三条流程写成代码然后把代码转化成论文和说明文档素材最后收在答辩演示的一个关键技巧上。2. 选型与数据建模为什么用 Django、五张核心表怎么落进 models.py2.1 Django 与 Flask 的选型逻辑管理类系统优先选 Django毕业设计的选型第一原则是用最小代价把“完成度”做出来。公务员考试信息管理系统是典型的 CRUD 密集型系统叫得上名的模块无非“公告管理、职位管理、报名审核、成绩登记”这类系统正好是 Django 的舒适区。对比项DjangoFlask后台管理自带 admin注册模型即可用没有内置需要自己写页面ORM 与迁移内置makemigrations/migrate 一条链依赖 SQLAlchemy 等第三方库认证与 Session内置 auth 应用需要扩展或自行实现适用场景结构化明确的管理信息系统轻量 API、单一功能页面这里并不是全盘否定 Flask。如果你的选题更偏“接口服务”或页面极少Flask 也做得完而且更容易在篇幅上做减法。但对一个多角色、多状态的招录系统Flask 的“自由”很快会变成重复造轮子用户登录要配后台列表要写分页搜索要自己处理这些都是答辩现场容易被追问的地方。Django 的自带功能不是注水它换来的是你把精力放在业务逻辑上——论文里就写“基于 Django 框架的二次开发”这是干净且真实的表述。2.2 核心表设计用户、公告、职位、报名、成绩这五张表就够了做数据建模时有一个常见的返工原因按页面来设计表而不是按流程来设计。页面会改流程相对固定。“发布公告 → 查看职位 → 提交报名 → 资格审核 → 录入成绩 → 结果公示”这条线里需要持久化的实体只有五个用户、招考公告、招聘职位、报名记录、考试成绩。用户表需要区分角色并保存考生身份信息公告表保存标题和正文职位表挂在公告下还要有报名起止时间报名记录是考生与职位的关联表承载审核状态成绩表与报名记录一对一存放笔试、面试、总分。用一个models.py把它们落下来# users/models.py from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): ROLE_CHOICES ( (admin, 管理员), (candidate, 考生), ) role models.CharField(角色, max_length20, choicesROLE_CHOICES, defaultcandidate) id_card models.CharField(身份证号, max_length18, blankTrue) phone models.CharField(联系电话, max_length11, blankTrue)# recruitment/models.py from django.db import models from django.conf import settings class Announcement(models.Model): title models.CharField(公告标题, max_length200) content models.TextField(公告内容) publish_time models.DateTimeField(发布时间, auto_now_addTrue) is_published models.BooleanField(是否发布, defaultTrue) class Position(models.Model): STATUS_CHOICES ( (draft, 草稿), (open, 报名中), (closed, 已截止), ) department models.CharField(招考部门, max_length100) title models.CharField(职位名称, max_length100) headcount models.IntegerField(招录人数, default1) education models.CharField(学历要求, max_length50) status models.CharField(状态, max_length10, choicesSTATUS_CHOICES, defaultdraft) deadline models.DateTimeField(报名截止时间) class Application(models.Model): AUDIT_CHOICES ( (pending, 待审核), (approved, 已通过), (rejected, 已退回), ) candidate models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.CASCADE, related_nameapplications ) position models.ForeignKey(Position, on_deletemodels.CASCADE, related_nameapplications) apply_time models.DateTimeField(报名时间, auto_now_addTrue) audit_status models.CharField(审核状态, max_length10, choicesAUDIT_CHOICES, defaultpending) audit_remark models.TextField(审核备注, blankTrue) class Meta: constraints [ models.UniqueConstraint(fields[candidate, position], nameunique_application) ] class ExamResult(models.Model): application models.OneToOneField(Application, on_deletemodels.CASCADE, related_nameresult) xingce_score models.DecimalField(行测成绩, max_digits5, decimal_places2) shenlun_score models.DecimalField(申论成绩, max_digits5, decimal_places2) interview_score models.DecimalField(面试成绩, max_digits5, decimal_places2, nullTrue, blankTrue) total_score models.DecimalField(总成绩, max_digits5, decimal_places2)有两处值得单独解释。第一自定义 User 时必须通过settings.AUTH_USER_MODEL引用而不是直接from django.contrib.auth.models import User否则 Django 在迁移时会提示系统用户模型冲突这几乎是从零开始就会踩的坑。第二UniqueConstraint(fields[candidate, position])是数据库层面的唯一约束它的作用是“同一个考生不能重复报同一个职位”这一行在并发场景下比在视图里先查询再判断更可靠。2.3 初始化项目并激活后台跑起来再说模型定义完成后初始化 Django 项目这一步顺序不要乱mkdir exam_system cd exam_system python -m venv venv venv\Scripts\activate # Windows source venv/bin/activate # macOS/Linux pip install django django-admin startproject exam_system . python manage.py startapp users python manage.py startapp recruitment项目创建后在settings.py的INSTALLED_APPS里加入users和recruitment同时配置AUTH_USER_MODEL users.User。接下来把模型注册到 admin 后台# recruitment/admin.py from django.contrib import admin from .models import Position, Application, ExamResult admin.register(Position) class PositionAdmin(admin.ModelAdmin): list_display (department, title, headcount, status, deadline) list_filter (status, department) admin.register(Application) class ApplicationAdmin(admin.ModelAdmin): list_display (candidate, position, audit_status, apply_time) list_filter (audit_status,)注册后运行迁移命令再到浏览器里验证python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runservermakemigrations会根据模型生成迁移文件migrate把迁移应用到数据库createsuperuser创建后台管理员账号runserver启动本地开发服务。这里有一个高频报错如果用户在已有数据的表上新增了非空字段makemigrations会要求你提供默认值或设置nullTrue不要用删库来逃避那会让论文里的“数据库设计”部分失去依据。3. 业务代码实现报名、审核、成绩三条流程怎么串起来3.1 考生端职位列表、提交报名、防止重复报名考生端的第一件事是看职位。先写一个职位列表视图只展示状态为“报名中”的职位# recruitment/views.py from django.shortcuts import render, redirect, get_object_or_404 from django.contrib.auth.decorators import login_required from django.contrib import messages from .models import Position, Application login_required def position_list(request): positions Position.objects.filter(statusopen) return render(request, recruitment/position_list.html, { positions: positions, })login_required的作用是拦截未登录用户Django 会把它重定向到登录页filter(statusopen)把“草稿”和“已截止”的职位排除掉避免考生在报名已经结束之后还能看到入口。这个小过滤条件对应论文里的“非功能需求数据有效性控制”答辩时是能展开讲的点。提交报名是核心逻辑代码要同时处理两件事职位是否可报、是否已经报过。login_required def apply_position(request, pk): position get_object_or_404(Position, pkpk, statusopen) if Application.objects.filter(candidaterequest.user, positionposition).exists(): messages.error(request, 你已经报过该职位不能重复提交) return redirect(position_list) Application.objects.create( candidaterequest.user, positionposition, audit_statuspending ) messages.success(request, 报名提交成功等待管理员审核) return redirect(position_list)get_object_or_404(Position, pkpk, statusopen)做的是两件事按主键查职位同时校验职位状态。如果职位不存在或已截止用户看到的直接是 404 页面这样“已截止的职位仍能提交”这类脏数据出现的概率会低很多。重复报名的校验用了exists()它只判断记录是否存在比先get()再捕获异常更直观。不过注意视图层的校验只是用户体验的一部分真正防止两个请求同时到达导致数据重复的是 2.2 节里那条数据库唯一约束——这两层要在论文的“系统设计”中分开写。3.2 管理员端报名审核与批量操作审核流程的状态流转交代清楚整个系统的骨架就立住了环节触发动作前置状态目标状态说明提交报名考生点击报名—待审核唯一约束防止重复审核通过管理员操作待审核已通过可填写审核备注审核退回管理员操作待审核已退回考生可查看退回原因成绩录入管理员录入已通过—通过后才有资格录入结果公示管理员发布已有成绩—按总分降序排列管理员审核单个报名记录一个函数视图即可login_required def audit_application(request, pk): application get_object_or_404(Application, pkpk) if request.user.role ! admin: messages.error(request, 只有管理员可以执行审核操作) return redirect(position_list) new_status request.POST.get(audit_status) if new_status in (approved, rejected): application.audit_status new_status application.audit_remark request.POST.get(audit_remark, ) application.save(update_fields[audit_status, audit_remark]) messages.success(request, 审核结果已保存) return redirect(application_list)这里request.user.role ! admin是简单的角色校验基于 2.2 节定义的User.role字段update_fields参数让save()只更新指定的两列避免把整条记录的其他字段重写一遍。对审计类表单来说这算是一个职业习惯——数据表里如果还有apply_time、create_time这类字段全量保存时很容易因为覆盖问题产生脏数据。审核列表场景通常存在批量操作。后台一次打开几十条待审核记录一条一条点确认并不现实用 Django ORM 的批量更新可以在一条 SQL 里完成login_required def audit_batch(request): application_ids request.POST.getlist(application_ids) action request.POST.get(action) if action in (approve, reject) and application_ids: new_status approved if action approve else rejected Application.objects.filter(id__inapplication_ids).update( audit_statusnew_status ) return redirect(application_list)filter(id__inapplication_ids).update(...)在数据库层直接执行 UPDATE不会触发每一行的模型save()逻辑速度更快也避免了 for 循环里逐条保存的重复代码。你的导师如果追问“这样做和循环 save 有什么区别”回答要点是update()不走 ORM 信号适合纯状态修改如果需要同时记录审核人、审核时间等字段就回到循环里逐个save()。这两种写法分别在论文“系统设计”和“系统实现”里出现工作量也好看。3.3 成绩模块Excel 导入、查询、排名成绩录入的方式有两种管理后台手工填写以及从 Excel 表格批量导入。现实场景里几十上百个考生的成绩靠手工录入不现实用openpyxl读取 xlsx 文件是常见做法# recruitment/services.py from openpyxl import load_workbook from .models import ExamResult def import_scores(file_path): wb load_workbook(file_path) ws wb.active for row in ws.iter_rows(min_row2, values_onlyTrue): application_id, xingce, shenlun row[0], row[1], row[2] ExamResult.objects.update_or_create( application_idapplication_id, defaults{ xingce_score: xingce, shenlun_score: shenlun, } ) return 导入完成iter_rows(min_row2, values_onlyTrue)从第二行开始读跳过表头update_or_create做的事情是按application_id查找找不到则创建找到了则更新成绩。这样同一个 Excel 文件重复导入多次结果也是幂等的不会出现成绩被重复插入的情况。成绩排名和查询是考生端跑得最多的一个页面from django.db.models import F login_required def result_list(request): results ExamResult.objects.select_related( application__candidate ).order_by(-total_score) return render(request, recruitment/result_list.html, { results: results, })order_by(-total_score)按总分降序排列select_related把成绩关联的报名记录和考生信息提前 join 出来避免在模板里逐条访问result.application.candidate.username时产生 N1 次查询。这个优化写在论文的“系统性能设计”一节里非常合适。4. 论文与说明文档代码写完后怎么把工作量翻译成看得见的交付物4.1 论文目录直接跟着系统模块走毕设论文看的是“逻辑闭环”目录最好直接对应系统模块不要先写一堆技术介绍再回头找功能。推荐骨架是第一章 绪论研究背景、意义、现状、论文结构第二章 相关技术Python、Django、MySQL、前端框架第三章 系统分析可行性分析、需求分析、用例图第四章 系统设计架构设计、模块划分、数据库 E-R 图第五章 系统实现按公告管理、职位管理、报名管理、审核管理、成绩管理逐节写第六章 系统测试测试环境、测试用例、测试结果这套结构的优势在于一、二章是模板三四章有建模内容支撑第五章就是代码注释的改写工作量分布均匀。避免把论文写成“Python 教程”因为评审老师要看的是“你怎么解决业务问题”而不是“你会不会用 requests 库”。4.2 从代码生成 E-R 图和用例图数据库 E-R 图不用手画。Django 有一个方便的命令能从现有模型直接生成图文件适合在论文第四章引用pip install pydot django-extensions # settings.py 的 INSTALLED_APPS 里加 django_extensions python manage.py graph_models recruitment users -o er_model.pnggraph_models recruitment users指定要扫描的应用输出er_model.png。生成的图会显示每个模型的字段和表间外键关系。需要注意E-R 图的美观度有限字段多时箭头会交叉论文里建议在 draw.io 里稍微重排一下布局或者只截取核心部分。用例图按两个角色画考生涉及注册登录、浏览公告、查询职位、在线报名、查看审核状态、查询成绩管理员涉及登录、发布公告、管理职位、审核报名、录入成绩、生成公示。把参与者画清楚期末答辩老师第一眼扫过去就知道系统角色划分是对的。状态图不要用网上模板直接用 3.2 节那张状态流转表去画更贴合你的代码实现。4.3 说明文档的定位写部署和演示步骤不写教程说明文档要能解决“拿到代码的人怎么跑起来”的问题。一个够用的 README 模板# 公务员考试信息管理系统 ## 1. 环境要求 - Python 3.10 及以上 - Django 4.x / 5.x - MySQL 8.0 或 SQLite 3 ## 2. 部署步骤 1. python -m venv venv 创建虚拟环境并激活 2. pip install -r requirements.txt 3. 修改 settings.py 中的数据库连接配置 4. python manage.py makemigrations 5. python manage.py migrate 6. python manage.py createsuperuser 创建管理员 7. python manage.py runserver 启动服务 ## 3. 默认账号 - 管理员admin / 自行设置 - 考生在注册页面注册即可实际操作中很多同学的说明文档只有寥寥几句“修改配置”。正确的做法是把pip install -r requirements.txt能跑通作为底线把“第一次启动后点哪些菜单、创建什么数据”写进去。演示时按文档操作一遍顺带也验证了文档的正确性——这一步在答辩评分里比重不低。测试部分的说明文档用功能测试表每一条对应一个可验证的操作用例编号用例名称前置条件操作步骤预期结果TC-01考生注册未登录进入注册页填写信息注册成功并跳转登录TC-02职位报名已登录职位报名中点击报名提示报名成功状态为待审核TC-03重复报名已报名同一职位再次点击报名提示不能重复报名TC-04管理员审核存在待审核报名审核通过考生端状态变为已通过这里有个小技巧测试表放在论文第六章但说明文档里也放一份可以起到“自测清单”的作用。答辩前的调试让说明文档发挥价值远比现场翻代码高效。5. 答辩演示前的一个关键技巧用 fixture 固定“干净状态”答辩演示翻车大多不是功能不存在而是系统状态太乱。比如演示时点开报名列表里面是几天前乱建的数据或者演示到一半被一条脏数据拦住这时候现场理数据非常被动。解决办法是不要手工清数据库用 Django 的 fixture 做“数据快照”。用dumpdata把业务表导出为 JSON 文件python manage.py dumpdata recruitment.Announcement recruitment.Position \ recruitment.Application recruitment.ExamResult users.User \ --indent 2 -o fixtures/demo_data.jsondumpdata后面跟的是“应用.模型”这条命令会把五个业务表的数据按缩进格式导出到demo_data.json。接下来在答辩演示前执行恢复操作python manage.py flush --noinput python manage.py loaddata fixtures/demo_data.jsonflush会清空所有表数据并保留表结构loaddata再把demo_data.json里的数据重新导入。两条命令一执行系统就回到“一个干净但数据完整”的起点。针对这个项目建议导出两组 fixture一组是“报名进行中”状态包含若干已报名但未审核的数据用于演示审核流程另一组是“成绩已发布”状态用于演示成绩查询和排名。演示顺序固定为“登录 → 发布公告 → 报名 → 审核 → 录成绩 → 查排名”每一步在 fixture 里都能对应到具体数据讲解时会更从容。另外有个调试相关的小提醒如果答辩现场要在 PyCharm 或 VSCode 里打断点演示源码先确认是以 Debug 模式启动服务否则会碰到“当前不会命中断点”的提示这种问题看起来很基础但在台上解释起来很尴尬。演示前把这一轮流程走一遍确认调试器和数据状态都正常再谈发挥。本文还有配套的精品资源点击获取 基于Python Django的公务员考试信息管理系统设计与实现
简介一套完整的计算机专业毕业设计项目方案基于 Python 与 Django 构建公务员考试信息管理系统包含论文、源代码和说明文档覆盖职位查询、个性化推荐、在线报名、考试提醒与数据分析等核心功能。压缩包共739个文件大小约19.83MB主要包含 Vue 前端组件、Python 后端代码、JS/CSS 页面、SQL 数据库脚本和 docx 论文文档结构清晰便于定位。系统采用前后端分离思路后端基于 Django数据库选用 MySQL前端以 Vue 和 HTML/CSS/JavaScript 为主信息查询、职位推荐、在线报名、考试提醒、数据分析等模块完整能支撑毕业设计展示与功能扩展。源码带有较详细注释说明文档对功能模块、部署流程和数据库设计作出梳理可支撑毕业设计调试、论文撰写或二次开发扩展。目前已有143人学习相关目录和模块结构完整适合课程设计、毕业设计或公务员考试信息管理方向的实战参考。1. 用 Python 做公务员考试信息管理系统难度刚好处在“能独立完成”这一档如果把“公务员考试信息管理系统”拆成业务线并不长招考单位发布公告和职位表考生注册后查看信息并在线报名管理员逐条做资格审核笔试面试结束之后录入成绩系统按排名生成公示名单。你把这个流程做成一个可演示的项目就同时覆盖了两个角色、一组带状态流转的报名单、至少一个数据汇总场景恰好踩中毕业设计评分表里“工作量、数据库设计、文档完整度”这三块。选 Python 的价值不在语言本身而在框架生态。用 Django 这类框架admin 后台、登录认证、ORM 全是现成的代码量能压到 3000 行以内论文里也好交代——哪部分是框架复用哪部分是业务扩展一句话就能说明白。下面沿着一个真实项目的迭代顺序走先定技术选型和数据模型再把报名、审核、成绩三条流程写成代码然后把代码转化成论文和说明文档素材最后收在答辩演示的一个关键技巧上。2. 选型与数据建模为什么用 Django、五张核心表怎么落进 models.py2.1 Django 与 Flask 的选型逻辑管理类系统优先选 Django毕业设计的选型第一原则是用最小代价把“完成度”做出来。公务员考试信息管理系统是典型的 CRUD 密集型系统叫得上名的模块无非“公告管理、职位管理、报名审核、成绩登记”这类系统正好是 Django 的舒适区。对比项DjangoFlask后台管理自带 admin注册模型即可用没有内置需要自己写页面ORM 与迁移内置makemigrations/migrate 一条链依赖 SQLAlchemy 等第三方库认证与 Session内置 auth 应用需要扩展或自行实现适用场景结构化明确的管理信息系统轻量 API、单一功能页面这里并不是全盘否定 Flask。如果你的选题更偏“接口服务”或页面极少Flask 也做得完而且更容易在篇幅上做减法。但对一个多角色、多状态的招录系统Flask 的“自由”很快会变成重复造轮子用户登录要配后台列表要写分页搜索要自己处理这些都是答辩现场容易被追问的地方。Django 的自带功能不是注水它换来的是你把精力放在业务逻辑上——论文里就写“基于 Django 框架的二次开发”这是干净且真实的表述。2.2 核心表设计用户、公告、职位、报名、成绩这五张表就够了做数据建模时有一个常见的返工原因按页面来设计表而不是按流程来设计。页面会改流程相对固定。“发布公告 → 查看职位 → 提交报名 → 资格审核 → 录入成绩 → 结果公示”这条线里需要持久化的实体只有五个用户、招考公告、招聘职位、报名记录、考试成绩。用户表需要区分角色并保存考生身份信息公告表保存标题和正文职位表挂在公告下还要有报名起止时间报名记录是考生与职位的关联表承载审核状态成绩表与报名记录一对一存放笔试、面试、总分。用一个models.py把它们落下来# users/models.py from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): ROLE_CHOICES ( (admin, 管理员), (candidate, 考生), ) role models.CharField(角色, max_length20, choicesROLE_CHOICES, defaultcandidate) id_card models.CharField(身份证号, max_length18, blankTrue) phone models.CharField(联系电话, max_length11, blankTrue)# recruitment/models.py from django.db import models from django.conf import settings class Announcement(models.Model): title models.CharField(公告标题, max_length200) content models.TextField(公告内容) publish_time models.DateTimeField(发布时间, auto_now_addTrue) is_published models.BooleanField(是否发布, defaultTrue) class Position(models.Model): STATUS_CHOICES ( (draft, 草稿), (open, 报名中), (closed, 已截止), ) department models.CharField(招考部门, max_length100) title models.CharField(职位名称, max_length100) headcount models.IntegerField(招录人数, default1) education models.CharField(学历要求, max_length50) status models.CharField(状态, max_length10, choicesSTATUS_CHOICES, defaultdraft) deadline models.DateTimeField(报名截止时间) class Application(models.Model): AUDIT_CHOICES ( (pending, 待审核), (approved, 已通过), (rejected, 已退回), ) candidate models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.CASCADE, related_nameapplications ) position models.ForeignKey(Position, on_deletemodels.CASCADE, related_nameapplications) apply_time models.DateTimeField(报名时间, auto_now_addTrue) audit_status models.CharField(审核状态, max_length10, choicesAUDIT_CHOICES, defaultpending) audit_remark models.TextField(审核备注, blankTrue) class Meta: constraints [ models.UniqueConstraint(fields[candidate, position], nameunique_application) ] class ExamResult(models.Model): application models.OneToOneField(Application, on_deletemodels.CASCADE, related_nameresult) xingce_score models.DecimalField(行测成绩, max_digits5, decimal_places2) shenlun_score models.DecimalField(申论成绩, max_digits5, decimal_places2) interview_score models.DecimalField(面试成绩, max_digits5, decimal_places2, nullTrue, blankTrue) total_score models.DecimalField(总成绩, max_digits5, decimal_places2)有两处值得单独解释。第一自定义 User 时必须通过settings.AUTH_USER_MODEL引用而不是直接from django.contrib.auth.models import User否则 Django 在迁移时会提示系统用户模型冲突这几乎是从零开始就会踩的坑。第二UniqueConstraint(fields[candidate, position])是数据库层面的唯一约束它的作用是“同一个考生不能重复报同一个职位”这一行在并发场景下比在视图里先查询再判断更可靠。2.3 初始化项目并激活后台跑起来再说模型定义完成后初始化 Django 项目这一步顺序不要乱mkdir exam_system cd exam_system python -m venv venv venv\Scripts\activate # Windows source venv/bin/activate # macOS/Linux pip install django django-admin startproject exam_system . python manage.py startapp users python manage.py startapp recruitment项目创建后在settings.py的INSTALLED_APPS里加入users和recruitment同时配置AUTH_USER_MODEL users.User。接下来把模型注册到 admin 后台# recruitment/admin.py from django.contrib import admin from .models import Position, Application, ExamResult admin.register(Position) class PositionAdmin(admin.ModelAdmin): list_display (department, title, headcount, status, deadline) list_filter (status, department) admin.register(Application) class ApplicationAdmin(admin.ModelAdmin): list_display (candidate, position, audit_status, apply_time) list_filter (audit_status,)注册后运行迁移命令再到浏览器里验证python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runservermakemigrations会根据模型生成迁移文件migrate把迁移应用到数据库createsuperuser创建后台管理员账号runserver启动本地开发服务。这里有一个高频报错如果用户在已有数据的表上新增了非空字段makemigrations会要求你提供默认值或设置nullTrue不要用删库来逃避那会让论文里的“数据库设计”部分失去依据。3. 业务代码实现报名、审核、成绩三条流程怎么串起来3.1 考生端职位列表、提交报名、防止重复报名考生端的第一件事是看职位。先写一个职位列表视图只展示状态为“报名中”的职位# recruitment/views.py from django.shortcuts import render, redirect, get_object_or_404 from django.contrib.auth.decorators import login_required from django.contrib import messages from .models import Position, Application login_required def position_list(request): positions Position.objects.filter(statusopen) return render(request, recruitment/position_list.html, { positions: positions, })login_required的作用是拦截未登录用户Django 会把它重定向到登录页filter(statusopen)把“草稿”和“已截止”的职位排除掉避免考生在报名已经结束之后还能看到入口。这个小过滤条件对应论文里的“非功能需求数据有效性控制”答辩时是能展开讲的点。提交报名是核心逻辑代码要同时处理两件事职位是否可报、是否已经报过。login_required def apply_position(request, pk): position get_object_or_404(Position, pkpk, statusopen) if Application.objects.filter(candidaterequest.user, positionposition).exists(): messages.error(request, 你已经报过该职位不能重复提交) return redirect(position_list) Application.objects.create( candidaterequest.user, positionposition, audit_statuspending ) messages.success(request, 报名提交成功等待管理员审核) return redirect(position_list)get_object_or_404(Position, pkpk, statusopen)做的是两件事按主键查职位同时校验职位状态。如果职位不存在或已截止用户看到的直接是 404 页面这样“已截止的职位仍能提交”这类脏数据出现的概率会低很多。重复报名的校验用了exists()它只判断记录是否存在比先get()再捕获异常更直观。不过注意视图层的校验只是用户体验的一部分真正防止两个请求同时到达导致数据重复的是 2.2 节里那条数据库唯一约束——这两层要在论文的“系统设计”中分开写。3.2 管理员端报名审核与批量操作审核流程的状态流转交代清楚整个系统的骨架就立住了环节触发动作前置状态目标状态说明提交报名考生点击报名—待审核唯一约束防止重复审核通过管理员操作待审核已通过可填写审核备注审核退回管理员操作待审核已退回考生可查看退回原因成绩录入管理员录入已通过—通过后才有资格录入结果公示管理员发布已有成绩—按总分降序排列管理员审核单个报名记录一个函数视图即可login_required def audit_application(request, pk): application get_object_or_404(Application, pkpk) if request.user.role ! admin: messages.error(request, 只有管理员可以执行审核操作) return redirect(position_list) new_status request.POST.get(audit_status) if new_status in (approved, rejected): application.audit_status new_status application.audit_remark request.POST.get(audit_remark, ) application.save(update_fields[audit_status, audit_remark]) messages.success(request, 审核结果已保存) return redirect(application_list)这里request.user.role ! admin是简单的角色校验基于 2.2 节定义的User.role字段update_fields参数让save()只更新指定的两列避免把整条记录的其他字段重写一遍。对审计类表单来说这算是一个职业习惯——数据表里如果还有apply_time、create_time这类字段全量保存时很容易因为覆盖问题产生脏数据。审核列表场景通常存在批量操作。后台一次打开几十条待审核记录一条一条点确认并不现实用 Django ORM 的批量更新可以在一条 SQL 里完成login_required def audit_batch(request): application_ids request.POST.getlist(application_ids) action request.POST.get(action) if action in (approve, reject) and application_ids: new_status approved if action approve else rejected Application.objects.filter(id__inapplication_ids).update( audit_statusnew_status ) return redirect(application_list)filter(id__inapplication_ids).update(...)在数据库层直接执行 UPDATE不会触发每一行的模型save()逻辑速度更快也避免了 for 循环里逐条保存的重复代码。你的导师如果追问“这样做和循环 save 有什么区别”回答要点是update()不走 ORM 信号适合纯状态修改如果需要同时记录审核人、审核时间等字段就回到循环里逐个save()。这两种写法分别在论文“系统设计”和“系统实现”里出现工作量也好看。3.3 成绩模块Excel 导入、查询、排名成绩录入的方式有两种管理后台手工填写以及从 Excel 表格批量导入。现实场景里几十上百个考生的成绩靠手工录入不现实用openpyxl读取 xlsx 文件是常见做法# recruitment/services.py from openpyxl import load_workbook from .models import ExamResult def import_scores(file_path): wb load_workbook(file_path) ws wb.active for row in ws.iter_rows(min_row2, values_onlyTrue): application_id, xingce, shenlun row[0], row[1], row[2] ExamResult.objects.update_or_create( application_idapplication_id, defaults{ xingce_score: xingce, shenlun_score: shenlun, } ) return 导入完成iter_rows(min_row2, values_onlyTrue)从第二行开始读跳过表头update_or_create做的事情是按application_id查找找不到则创建找到了则更新成绩。这样同一个 Excel 文件重复导入多次结果也是幂等的不会出现成绩被重复插入的情况。成绩排名和查询是考生端跑得最多的一个页面from django.db.models import F login_required def result_list(request): results ExamResult.objects.select_related( application__candidate ).order_by(-total_score) return render(request, recruitment/result_list.html, { results: results, })order_by(-total_score)按总分降序排列select_related把成绩关联的报名记录和考生信息提前 join 出来避免在模板里逐条访问result.application.candidate.username时产生 N1 次查询。这个优化写在论文的“系统性能设计”一节里非常合适。4. 论文与说明文档代码写完后怎么把工作量翻译成看得见的交付物4.1 论文目录直接跟着系统模块走毕设论文看的是“逻辑闭环”目录最好直接对应系统模块不要先写一堆技术介绍再回头找功能。推荐骨架是第一章 绪论研究背景、意义、现状、论文结构第二章 相关技术Python、Django、MySQL、前端框架第三章 系统分析可行性分析、需求分析、用例图第四章 系统设计架构设计、模块划分、数据库 E-R 图第五章 系统实现按公告管理、职位管理、报名管理、审核管理、成绩管理逐节写第六章 系统测试测试环境、测试用例、测试结果这套结构的优势在于一、二章是模板三四章有建模内容支撑第五章就是代码注释的改写工作量分布均匀。避免把论文写成“Python 教程”因为评审老师要看的是“你怎么解决业务问题”而不是“你会不会用 requests 库”。4.2 从代码生成 E-R 图和用例图数据库 E-R 图不用手画。Django 有一个方便的命令能从现有模型直接生成图文件适合在论文第四章引用pip install pydot django-extensions # settings.py 的 INSTALLED_APPS 里加 django_extensions python manage.py graph_models recruitment users -o er_model.pnggraph_models recruitment users指定要扫描的应用输出er_model.png。生成的图会显示每个模型的字段和表间外键关系。需要注意E-R 图的美观度有限字段多时箭头会交叉论文里建议在 draw.io 里稍微重排一下布局或者只截取核心部分。用例图按两个角色画考生涉及注册登录、浏览公告、查询职位、在线报名、查看审核状态、查询成绩管理员涉及登录、发布公告、管理职位、审核报名、录入成绩、生成公示。把参与者画清楚期末答辩老师第一眼扫过去就知道系统角色划分是对的。状态图不要用网上模板直接用 3.2 节那张状态流转表去画更贴合你的代码实现。4.3 说明文档的定位写部署和演示步骤不写教程说明文档要能解决“拿到代码的人怎么跑起来”的问题。一个够用的 README 模板# 公务员考试信息管理系统 ## 1. 环境要求 - Python 3.10 及以上 - Django 4.x / 5.x - MySQL 8.0 或 SQLite 3 ## 2. 部署步骤 1. python -m venv venv 创建虚拟环境并激活 2. pip install -r requirements.txt 3. 修改 settings.py 中的数据库连接配置 4. python manage.py makemigrations 5. python manage.py migrate 6. python manage.py createsuperuser 创建管理员 7. python manage.py runserver 启动服务 ## 3. 默认账号 - 管理员admin / 自行设置 - 考生在注册页面注册即可实际操作中很多同学的说明文档只有寥寥几句“修改配置”。正确的做法是把pip install -r requirements.txt能跑通作为底线把“第一次启动后点哪些菜单、创建什么数据”写进去。演示时按文档操作一遍顺带也验证了文档的正确性——这一步在答辩评分里比重不低。测试部分的说明文档用功能测试表每一条对应一个可验证的操作用例编号用例名称前置条件操作步骤预期结果TC-01考生注册未登录进入注册页填写信息注册成功并跳转登录TC-02职位报名已登录职位报名中点击报名提示报名成功状态为待审核TC-03重复报名已报名同一职位再次点击报名提示不能重复报名TC-04管理员审核存在待审核报名审核通过考生端状态变为已通过这里有个小技巧测试表放在论文第六章但说明文档里也放一份可以起到“自测清单”的作用。答辩前的调试让说明文档发挥价值远比现场翻代码高效。5. 答辩演示前的一个关键技巧用 fixture 固定“干净状态”答辩演示翻车大多不是功能不存在而是系统状态太乱。比如演示时点开报名列表里面是几天前乱建的数据或者演示到一半被一条脏数据拦住这时候现场理数据非常被动。解决办法是不要手工清数据库用 Django 的 fixture 做“数据快照”。用dumpdata把业务表导出为 JSON 文件python manage.py dumpdata recruitment.Announcement recruitment.Position \ recruitment.Application recruitment.ExamResult users.User \ --indent 2 -o fixtures/demo_data.jsondumpdata后面跟的是“应用.模型”这条命令会把五个业务表的数据按缩进格式导出到demo_data.json。接下来在答辩演示前执行恢复操作python manage.py flush --noinput python manage.py loaddata fixtures/demo_data.jsonflush会清空所有表数据并保留表结构loaddata再把demo_data.json里的数据重新导入。两条命令一执行系统就回到“一个干净但数据完整”的起点。针对这个项目建议导出两组 fixture一组是“报名进行中”状态包含若干已报名但未审核的数据用于演示审核流程另一组是“成绩已发布”状态用于演示成绩查询和排名。演示顺序固定为“登录 → 发布公告 → 报名 → 审核 → 录成绩 → 查排名”每一步在 fixture 里都能对应到具体数据讲解时会更从容。另外有个调试相关的小提醒如果答辩现场要在 PyCharm 或 VSCode 里打断点演示源码先确认是以 Debug 模式启动服务否则会碰到“当前不会命中断点”的提示这种问题看起来很基础但在台上解释起来很尴尬。演示前把这一轮流程走一遍确认调试器和数据状态都正常再谈发挥。本文还有配套的精品资源点击获取