基于Python和Vue3的学科竞赛管理系统毕业设计全解析

简介：这份资源是一篇基于Python、Django、Vue与MySQL的校园学科竞赛管理系统毕业论文，适合高校计算机相关专业学生、毕业设计选题者及希望了解B/S架构Web系统开发流程的开发者参考。论文围绕竞赛信息发布不及时、报名流程繁琐、成绩统计不准确等传统管理痛点，给出了包含学生模块、竞赛信息模块、报名竞赛模块、成绩排名模块在内的完整系统设计方案，并对B/S三层架构、Django后端框架、Vue前端界面及MySQL数据库的集成实现进行了详细阐述。压缩包内含1个doc文档，大小约15.93MB，论文结构完整，包含摘要、中英文关键词、系统设计、功能实现等章节，可作为毕业设计撰写、系统功能规划及答辩准备的参考资料。目前已有50人学习，对于需要快速把握学科竞赛管理系统需求分析和技术选型的读者，能提供清晰的框架借鉴与实现思路。

1. 选题拆解：这个毕业论文项目到底要做什么

看到"Python-vue3校园学科竞赛管理系统"这个题目，很多人的第一反应是"又一个管理系统"，确实，从技术难度上说，这类项目比推荐算法、图像识别那些热门方向要朴实得多。但恰恰是这种"朴实"让它成为毕业论文的稳妥选择：业务边界清晰、需求分析好画、数据库设计有逻辑可讲、前后端联调闭环完整，答辩的时候老师问起来，每一个环节你都能拿出实实在在的东西。

这套系统解决的是学校里学科竞赛组织混乱的问题。我在本科阶段帮老师整理过竞赛报名表，深有体会：赛讯靠群消息转发，报名靠收集Excel，成绩靠人工核对，最后统计排名时经常发现学号写错、分数漏录。做一个线上管理系统，就是把"发布竞赛—在线报名—材料提交—评委评分—成绩排名—证书导出"这条完整链路搬到Web端，让管理员、教师、学生各自的操作都在系统里留痕。

核心用户角色就三类：系统管理员维护竞赛信息和用户账号，教师/评委负责审核报名和打分，学生负责浏览赛讯、报名参赛和查看成绩。注意，这里有一个很多初学者会忽略的点：角色设计直接决定了权限模型的复杂度，它影响后端的接口鉴权方案，也影响前端路由守卫的写法。如果一开始就把角色理清楚，后面开发能省掉大量返工。

技术站位上，题目已经锁定Python和Vue3，这是国内毕设非常成熟的组合，社区资料多、踩坑答案全，适合一个人独立开发。前端Vue3负责页面交互和状态管理，后端Python提供RESTful API，前后端通过JSON数据通信，正好对应论文章节里"前后端分离架构"那一节，写起来既有图又有真话可说。

1.1 业务模块与用户故事

先别急着写代码，把模块拆清楚。我用用户故事的方式过一遍核心场景：

• 管理员登录后台，创建一场"全国大学生数学建模竞赛校级选拔赛"，设置报名截止时间、参赛要求、附件模板。
• 学生登录后看到竞赛列表，点击报名，填写队伍信息，上传作品材料。
• 教师登录后看到待审核列表，通过或驳回报名，报名截止后对作品打分，填分数和评语。
• 系统按分数自动排名，管理员导出Excel成绩单和获奖名单。

围绕这些场景，系统拆成这几个模块：用户认证与权限管理、竞赛信息管理、报名管理、作品提交、成绩评定、公告通知、数据统计。每个模块之间不是孤立的，比如报名模块要校验竞赛状态（报名中/已截止/进行中），成绩模块要判断报名是否通过审核，这些关联关系就是论文里"业务流程设计"的素材。

我建议做毕设的同学把每个模块的状态机画出来，不要只画用例图。比如报名这条线：已提交→待审核→已通过/已驳回；竞赛这条线：草稿→报名中→评审中→已结束。状态机画清楚了，数据库设计基本就完成了一半。

1.2 技术选型：Python框架选哪个更合适

Python写后端，框架无非三个选项：Flask、Django、FastAPI。我直接给结论：毕业论文项目首选Flask，其次是FastAPI，Django看情况。

Flask胜在轻量和灵活，学起来快，数据库用什么ORM自己说了算，推荐配Flask-SQLAlchemy + PyMySQL。Django自带Admin后台和ORM，开发效率高，但框架思想重，如果答辩时被问到底层原理，比如中间件执行流程，答不上来反而减分。FastAPI性能好，自带接口文档，但生态相对薄，国内论文里用它的比例还在上升期。

我个人的毕业设计是用Flask + MySQL + Flask-JWT-Extended做的，整套下来代码量不大，后续写论文时每个装饰器、每个配置项都能讲清楚来龙去脉。选Python还有一个隐性好处：答辩时老师大概率会问"为什么选Python"，你至少可以说"Python生态完善，Flask轻量易扩展，适合快速开发中小型Web应用"，这个回答安全又合理。

前端这边，Vue3建议直接用Vite构建，搭配Vue Router做路由、Pinia做状态管理、Axios做请求、Element Plus做UI组件库。Element Plus的表格、表单、日期选择器、上传组件几乎覆盖了系统所有页面需求，不用自己手写复杂样式。

2. 数据库设计：表结构怎么建才经得起答辩质问

数据库设计是论文评审的重点关注区域，也是系统能跑通的地基。我设计的时候遵循一个原则：每个表都能回答一个业务问题。下面给出核心表的简化设计，你可以直接参考着改。

2.1 核心表结构

用户表（user）：id、username、password_hash、role（admin/teacher/student）、real_name、student_no（学号）、email、created_at。用户表用角色字段区分三种身份，不用建三张表分开存，因为公共字段多，一张表加角色枚举最简单。

竞赛表（competition）：id、title、description、category（学科分类）、报名开始/结束时间、评审开始/结束时间、status（草稿/报名中/评审中/已结束）、cover_url（海报图）、created_by。这个表是系统的核心，几乎所有业务都围绕它展开。

报名表（registration）：id、competition_id、user_id、team_name、member_names（队友姓名，逗号分隔）、status（待审核/已通过/已驳回）、材料文件URL、created_at。注意这里加了一个team_name字段，因为学科竞赛很多是组队参加的。如果队伍信息复杂（比如要记录每个队员的学校学院），可以单独拆一张team表和一张registration_team关联表，看你的业务深度取舍。

成绩表（score）：id、competition_id、registration_id、judge_id、score、comment、created_at。一个报名记录可能被多个评委打分，所以成绩表要设计成一对多，最后平均分作为最终成绩。如果你的系统只让一个老师打分，那直接在registration表里加score字段也行，但多人评审的场景在论文里讲起来更饱满。

公告表（announcement）：id、title、content、publisher_id、created_at。用于发布赛讯和通知，简单的一张内容表就够。

2.2 外键与状态字段的设计细节

很多毕设项目的通病是外键约束加得太多，或者一层都不加。我的经验是：外键约束建议加上，但不要影响主要流程。比如registration表的competition_id、user_id可以加外键，保证数据完整性；但score表到registration表的外键建议保留，因为成绩必须关联有效报名记录。

状态字段强烈建议用字符串枚举而不是整数。比如报名状态用"pending / approved / rejected"，比1、2、3可读性强得多，写代码的时候不会记混，答辩展示数据库的时候老师也一眼能看懂。还要注意给所有表加上created_at和updated_at时间戳，这是通用习惯，也是论文里说"规范设计"的佐证。

索引方面，别在毕设里过度设计。给外键字段和竞赛表的status字段建索引就够了，数据量在这个量级上根本不走性能瓶颈，重点是逻辑清晰。

3. 后端核心实现：Python接口怎么写得既规范又省事

后端是整个系统的大脑，这部分的代码质量决定了论文"系统实现"一章能写多少页。我的建议是：先搭好项目骨架，再逐个模块填充，所有接口遵循RESTful风格，路径用名词复数、方法表动作。比如：

• GET /api/competitions 获取竞赛列表
• POST /api/competitions 创建竞赛
• GET /api/competitions/ 获取竞赛详情
• POST /api/registrations 提交报名

这样设计的接口，论文里画接口表格都不用额外编，直接列出来就是一张清晰的设计文档。

3.1 项目结构与认证方案

Flask项目我习惯按模块分包，而不是把所有路由写在一个app.py里：

backend/ ├── app.py # 应用入口 ├── config.py # 配置类 ├── models/ # ORM模型 │ ├── __init__.py │ ├── user.py │ ├── competition.py │ └── registration.py ├── routes/ # 蓝图路由 │ ├── __init__.py │ ├── auth.py │ ├── competition.py │ └── registration.py ├── utils/ # 工具函数 │ ├── decorators.py # 权限装饰器 │ ├── response.py # 统一返回格式 │ └── excel.py # Excel导出 └── requirements.txt

认证方案我强烈推荐JWT，因为它是无状态的，前端Vue3存token、每次请求放在Authorization头里就行。Flask-JWT-Extended这个库封装得很好，生成token和校验token的代码量很少。

from flask_jwt_extended import create_access_token, jwt_required, get_jwt_identity @app.post("/api/auth/login") def login(): data = request.get_json() user = User.query.filter_by(username=data["username"]).first() if user and check_password_hash(user.password_hash, data["password"]): token = create_access_token( identity=str(user.id), additional_claims={"role": user.role} ) return ok(data={"token": token, "role": user.role, "name": user.real_name}) return fail("用户名或密码错误")

注意我用了统一返回函数ok()和fail()，把所有接口响应固定成{"code": 200, "data": ..., "message": "success"}这样的格式。这个细节非常重要，前端Axios拦截器可以统一处理code，错误提示也统一展示，避免了前后端各写各的、联调时手忙脚乱的局面。

3.2 权限控制与业务校验

JWT的claims里塞了role字段，权限校验我封装了一个装饰器：

from functools import wraps from flask_jwt_extended import verify_jwt_in_request, get_jwt def role_required(*roles): def wrapper(fn): @wraps(fn) def decorator(*args, **kwargs): verify_jwt_in_request() claims = get_jwt() if claims.get("role") not in roles: return fail("无权限访问", code=403) return fn(*args, **kwargs) return decorator return wrapper

用的时候一行就能搞定：@role_required("admin")或@role_required("admin", "teacher")。这样的设计在论文里可以单独开一个小节讲"基于角色的访问控制（RBAC）设计"，内容既真实又专业。

业务校验才是后端最容易翻车的点。比如学生报名时，要检查竞赛状态是否为"报名中"、检查当前时间在不在报名时间窗口内、检查用户是否已经报名过。这些逻辑不要散落在路由函数里，我习惯抽成一个validate_registration(data)函数，集中处理，测试也好写。踩过的坑是：一开始把这些校验写在路由里，后面加需求改得想哭。

3.3 文件上传与成绩导出

竞赛报名经常需要传附件，比如PDF文档、压缩包。Flask处理文件上传配合werkzeug.utils.secure_filename做文件名清洗，文件路径存数据库。注意两个关键配置：

app.config["MAX_CONTENT_LENGTH"] = 50 * 1024 * 1024 # 限制50M

一个是上传大小限制，不设的话用户传大文件会直接把服务拖垮，默认报错信息还很难看。另外建议指定UPLOAD_FOLDER目录，按uploads/竞赛id/用户id/文件名的方式组织，避免所有文件堆在一个目录里。

成绩导出Excel我用的是openpyxl，处理的是后端从数据库读出的成绩数据。生成后放在临时目录，用send_file返回给前端下载。这里有个细节：文件名如果带中文，要用url_quote处理，不然前端下载时文件名会变成一串乱码，这个小问题当时折腾了我两小时。

4. 前端核心实现：Vue3的工程化实践

Vue3相较Vue2最大的变化就是组合式API，配合<script setup>语法糖，写起来既简洁又直观。毕设里的页面多属于"表单+表格+弹窗"三类，用Vite创建一个Vue3项目后，我建议先把目录和请求层搭好，再写页面。

4.1 工程搭建与目录规划

frontend/ ├── src/ │ ├── api/ # 每个模块的请求函数 │ │ ├── auth.js │ │ ├── competition.js │ │ └── registration.js │ ├── components/ # 公共组件 │ ├── router/ # 路由配置 │ ├── stores/ # Pinia状态 │ │ ├── user.js │ │ └── app.js │ ├── views/ # 页面 │ │ ├── login.vue │ │ ├── admin/ │ │ ├── teacher/ │ │ └── student/ │ ├── utils/ # 请求封装、工具函数 │ └── App.vue

创建项目直接用Vite官方脚手架，选择vue模板即可，不要选vue-ts，毕设一般用JS更快。Element Plus的引入建议全量引入，毕设场景不需要考虑打包体积，全量引入省心。

4.2 Axios封装与Pinia状态管理

Axios封装是前端最重要的基础工作。我习惯在utils/request.js里创建一个实例，配置基础URL和超时时间，然后用拦截器做三件事：请求头加token、统一处理业务code、401时跳转登录页。

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response?.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.response?.data?.message || '网络异常') return Promise.reject(error) } ) export default request

Pinia用来管理当前登录用户的信息、权限、侧边栏折叠状态等全局数据。推荐用setup语法写store，更符合Vue3的组合式风格。

export const useUserStore = defineStore('user', () => { const token = ref(localStorage.getItem('token') || '') const userInfo = ref({}) const setLogin = (data) => { token.value = data.token userInfo.value = data localStorage.setItem('token', data.token) } const logout = () => { token.value = '' userInfo.value = {} localStorage.removeItem('token') } return { token, userInfo, setLogin, logout } })

4.3 路由守卫与组件通信

权限控制在前端也要做一道。路由配置时给每个路由加上meta: { roles: ['admin'] }这样的声明，然后全局前置守卫里判断当前用户的角色能不能访问这个路由。不能访问就跳转到首页或403页面。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else if (token && to.path === '/login') { next('/') } else { next() } })

Vue3的组件通信，毕设里最常见的就是父子组件传值，用props向下传、emit向上传就够了。如果你使用了Pinia，跨层级组件通信直接通过store解决，根本不用纠结Vue2时代"兄弟组件怎么通信"这类问题。需要注意的一点是defineProps和defineEmits在<script setup>里不用显式导入，直接调用宏函数就行。

Vue3生命周期和Vue2的差异也要留意。比如beforeDestroy改成了beforeUnmount，created里的逻辑可以放进onMounted或直接在setup顶层执行。答辩老师经常问"Vue2和Vue3区别"，提前总结这几点回答起来顺畅。

4.4 关键页面：竞赛列表与报名表单

以学生端竞赛列表为例，页面加载调用fetchCompetitions()，拿到数据后用reactive存列表，渲染在Element Plus的表格里。注意加载状态和空数据状态的展示，这两个细节是很多毕设作品看起来"粗糙"和"精致"的分水岭。

报名表单是另一个关键页面，因为要传文件。Element Plus的el-upload组件要设置:auto-upload="false"，手动拿到文件后用FormData和报名信息一起POST给后端。这里最容易踩的坑是：表单字段和文件一起上传时，后端要同时通过request.form和request.files来取数据，只处理一边会导致另一边的数据丢失。

5. 前后端联调与部署：让论文里的系统真正能跑起来

联调阶段最典型的问题就是跨域。开发环境下，Flask跑在5000端口，Vite跑在5173端口，浏览器会因为CORS策略拦截请求。解决办法有几种：

• 后端加flask-cors，允许所有来源访问；
• 前端Vite配置server.proxy代理，把/api开头的请求转发到5000端口；
• 生产环境用Nginx统一反向代理。

我推荐开发环境用Vite代理，代码里不用写绝对URL，所有请求走相对路径/api，后续部署到Nginx时几乎不用改前端代码。Vite配置如下：

// vite.config.js server: { proxy: { '/api': { target: 'http://127.0.0.1:5000', changeOrigin: true } } }

后端再加一层flask-cors兜底，双保险。

部署方案我试过两种：一种是传统方式，后端用Gunicorn启动Flask，前端npm run build后把dist目录交给Nginx托管，Nginx里配置location /api { proxy_pass http://127.0.0.1:5000; }。另一种是分两个服务部署，前端Nginx托管，后端单独跑在5000端口。毕设演示阶段，用第二种就够了，简单直观，你在学生电脑上打开浏览器输入地址就能看到效果。

部署时的坑：Flask启动要设置host='0.0.0.0'，不然局域网里其他设备访问不到，答辩现场用自己电脑演示或让老师手机访问都会遇到这个问题。

6. 常见问题与排查技巧实录

做这类毕设项目，踩坑是必然的。我把实际开发中最常遇到的问题整理成一张速查表，方便你边做边查。

再说两个独家经验。第一个是如何在答辩演示时避免翻车：准备一套带演示数据的数据库脚本，开场前把数据库恢复到初始状态，不要用手动输入数据的方式现填。第二个是关于requirements.txt：用pip freeze > requirements.txt时要把本地环境里无关的包清理掉，否则装依赖时会装一堆没用的库，甚至因为版本冲突装不上。

7. 论文与系统同步推进的建议

最后聊一个很多人忽视的问题：论文和代码往往是互相成就的。我在写论文时发现，系统实现章节的每个小节都可以对应到代码里的一个模块，比如"用户认证模块实现"对应auth路由，"报名功能实现"对应registration路由。建议先画清楚架构图再写代码，架构图里的组件就是论文的目录大纲，反过来，代码跑通后要把真实的接口文档和数据库表结构补充到论文附录里，不要用想象中的设计糊弄。

给即将开始的同学一个我的实操节奏：第一周搭框架（前后端骨架+数据库建表），第二周完成后端认证和竞赛管理功能，第三周完成报名和评分功能，第四周做前端页面联调，第五周补数据统计和导出功能，留一周时间专门测试和录演示视频。严格按照这个节奏来，绝对赶得上答辩。

愿意做这个题目的同学，说明你已经选择了最稳妥的路径，剩下的就是踏实把每一步落到实处。工程做完，论文写完，真正收获的不只是一个毕业设计，而是你第一次独立设计并交付一个完整系统的全过程能力，这种经验在以后的工作和学习里会持续给你回报。

本文还有配套的精品资源，点击获取