高校学科竞赛平台双端架构与RBAC权限管理实战

简介：这是一套面向高校学科竞赛管理场景的全栈式Web应用系统，适用于毕业设计、课程设计及工程实训等教学实践环节，为管理员、教师和学生三类角色提供统一平台支持，覆盖竞赛发布、师生管理、学院专业维护与获奖成果归档等核心业务。资源包共975个文件，包含217个Java后端逻辑文件、153个JavaScript前端交互脚本、70个Vue组件、83个HTML页面及44个CSS样式文件，辅以SQL数据库脚本与批处理运行脚本（如1-install.bat），整体压缩包仅20.75MB，结构清晰、模块解耦明确。已有42人下载学习，资源经实测可完整复现运行，附带说明文档与可直接部署的工程结构，支持在现有基础上快速二次开发或功能扩展。读者可直接复刻系统、借鉴模块设计思路、参考前后端协同实现方式，并用于大创项目立项或竞赛平台原型构建。 高校学科竞赛平台这类系统，我在实际项目中接触过不止一次，说实话，市面上能用的开源方案真不多，大部分学校要么用问卷星收集报名，要么靠教务处老师手工整理Excel，表格传来传去，一个报名信息都能对不上号。所以当你拿到一个“高校学科竞赛平台，分为管理后台和用户网页端”的项目时，它的核心价值不只是把报名搬到线上，而是把管理员、教师、学生三个角色从“人治”变成“流程治”。这篇文章我会从需求拆解、模块设计、技术实现、踩坑实录四个维度完整复盘，帮你看清这类平台的真实架构和落地思路。

1. 项目整体设计与角色权限拆解

1.1 为什么是“管理后台+用户网页端”的双端架构

先聊聊整体形态。你拿到的项目标题里写得很清楚：管理后台 + 用户网页端。这是绝大多数高校内部系统的标准分法，甚至可以说是一种“行业惯例”。为什么这么分？核心原因有两个：使用人群和操作频率。

管理后台的使用者是管理员和教师，操作频率高、权限敏感度高，需要处理用户管理、数据统计、审核审批这类重操作。而用户网页端的使用者主要是学生，使用频率低、路径简单，核心动作就三个：浏览竞赛、报名参赛、查看成绩和证书。把两类需求拆到两个端，可以让每一端的界面和信息架构都极简，不用在一个页面里既塞后台管理功能又塞学生报名入口，交互上不会打架。

从技术实现角度看，双端架构也更好维护。后台和网页端可以共用一套后端API，但前端代码完全分离，管理员端做得再复杂也不会影响学生端的加载性能，反之亦然。如果你用Vue这类前端框架，两个端可以是两个独立工程，也可以在同一个工程里用路由懒加载做区分，这个后面实操部分我会细说。

1.2 三角色权限模型的深层思考

项目里有管理员、教师、学生三个角色，这几乎是高校竞赛平台的标配。但设计权限模型时，最容易犯的错误是把角色权限做成“写死”的——管理员登录就显示全部菜单，教师登录就显示部分菜单，学生登录再显示一部分。听起来没问题，但一旦学校说“我们想让某个学院的老师只能管理自己学院的竞赛”，写死的权限就崩了，需要改代码重新部署。

所以，我在做类似项目时，第一件事就是引入RBAC（基于角色的访问控制）模型，哪怕项目只有三个角色，也要给后续留扩展空间。具体到你这个项目，三个角色的权限边界我建议这么划：

• 管理员：系统级权限，管理教师账号、重置密码、审核竞赛发布、查看全校获奖数据、配置学院和专业、管理公告。这是唯一的“超级角色”。
• 教师：业务级权限，发布竞赛、审核学生报名、录入获奖结果、查看自己负责竞赛的统计报表、维护个人资料。
• 学生：功能级权限，浏览竞赛列表、查看竞赛详情、在线报名、上传作品材料、查看自己的获奖记录和证书。

这样划分有一个隐藏好处：教师和学生之间天然形成了一条“发布→报名→审核→评奖”的业务闭环，管理员只做兜底和治理，不需要在每一个环节里当传话筒。

1.3 数据权限：比角色权限更隐蔽的坑

角色权限管的是“能不能点这个菜单”，数据权限管的是“能看到哪几条数据”。这个在高校竞赛平台里特别重要，因为竞赛是按学院、按专业组织的。

我实际遇到过一个典型场景：全校有20个学院，管理员给每个学院都设了负责人老师。如果不做数据权限隔离，A学院的老师登录后能看到B学院的获奖名单，甚至能修改B学院的竞赛信息，这在学校里就是严重的权限事故。所以，在做竞赛表设计时，一定要给竞赛加一个“所属院系”或“负责人”的外键，教师查询竞赛列表时，SQL里强制带条件：WHERE teacher_id = 当前登录用户ID。前端菜单可以都一样，但后端返回的数据必须做了过滤。

这一点务必在项目开发阶段就实现，别等上线后被学院负责人投诉“串数据”再补，那时候改起来会牵扯到所有接口，成本翻倍。

2. 五大核心模块逐个拆解

2.1 教师管理模块：从账号导入到角色分配

教师管理模块本质上是一个“后台用户管理”的子集，但高校场景下有一些特殊需求。

第一是账号初始化。高校教师的账号来源通常是人事系统或教务系统，但在竞赛平台里，最省事的做法是管理员手动添加或批量Excel导入。手动添加的字段建议至少包含：工号、姓名、性别、所属学院、手机号、邮箱、初始密码。批量导入时要注意Excel模板的格式校验，我遇到过老师把工号列填成文本格式导致导入后前导零丢失的情况——工号是000123，导入后变成123，这个问题可以用“导入前先检测列格式，强制转文本”来解决。

第二是教师角色分配。同一个教师可能既是竞赛负责人，又是评委，这时候不要设计成“一个教师只能有一个角色”，而是在教师表里加一个角色字段，或者在关联表里记录。如果项目要求更细，还可以给教师分配“竞赛管理员”的权限范围，即他能管理哪些院系或哪些竞赛类别，这又回到了前面说的数据权限。

第三是密码安全。高校系统往往会忽略这一点，但平台里教师的权限不小，一旦账号泄露可能影响比赛公平性。建议至少做到：初始密码强制修改、密码加密存储（BCrypt或PBKDF2）、连续输错5次锁定账号30分钟。这些功能实现起来不复杂，但对系统安全性的提升非常明显。

2.2 学生管理模块：学号是天然的唯一键

学生管理模块的数据来源比教师更清晰，因为学生学号是天然的全局唯一标识。但要注意几个坑。

第一，学生信息怎么进来？两种方式：一是对接教务系统定时同步，二是由管理员批量导入或学生自行注册。多数学校在平台上线初期都会采用第二种，因为对接教务系统涉及跨部门协调，周期长。如果走学生自行注册，注册时建议只让学生填学号、姓名、学院、专业、年级、手机号、邮箱，提交后由管理员审核通过才能登录。审核这一步很重要，否则任何人都可以用“123456”这种学号注册，后台数据会变得很脏。

第二，学院和专业信息怎么存？我见过很多学生表直接把专业名称存成字符串，结果出现“计算机科学与技术”和“计算机科学与技木”这种肉眼看起来一样、数据库里对不上的脏数据。正确做法是：学生表中存的是专业ID外键，专业名通过关联查询获取。这就是项目里有独立“学院专业模块”的原因——它是整个系统的数据字典基础。

第三，学生状态管理。毕业、休学、转专业、退学，这些状态如果不在平台里标记，会出现老学长毕业后还能登录系统报名竞赛的情况。建议学生表里加一个“在校状态”字段，离校学生自动禁用登录权限。

2.3 竞赛信息模块：不只是发布一条公告

竞赛信息模块是整个平台的信息中枢，设计和实现直接影响用户体验。一个竞赛的基本信息至少包含：竞赛名称、类别（学科类/创新创业类/技能类等）、级别（国家级/省级/校级/院级）、主办单位、承办学院、面向对象（全校/指定学院/指定专业）、报名开始时间、报名截止时间、竞赛开始时间、竞赛结束时间、竞赛简介、竞赛章程附件、联系人信息。

比基本字段更重要的是竞赛的状态流转。我建议把竞赛状态设计成以下五个：草稿、已发布、报名中、进行中、已结束。状态之间不是随意切换的，而是有规则：

• 草稿 → 已发布：教师完善竞赛信息后提交，管理员审核通过。
• 已发布 → 报名中：系统到达报名开始时间自动切换，或管理员手动开启。
• 报名中 → 进行中：报名截止时间到达后自动切换，之后学生不可以再报名。
• 进行中 → 已结束：竞赛结束时间到达，或管理员手动结束。

状态流转用“时间自动+人工修正”的双机制，可以避免管理员半夜被电话吵醒去改竞赛状态这种破事。

另外，竞赛报名设置也要细。一个竞赛是个人赛还是团队赛？团队赛最多几个人？团队是否允许跨学院组队？这些字段决定了报名模块的逻辑复杂度。个人赛报名只需要填个人资料，团队赛报名则需要创建团队、添加成员、设置队长，每个人的信息都要校验。这个模块做好了，后面获奖管理关联团队或个人时才不会出问题。

2.4 学院专业模块：看似简单却是数据地基

学院专业模块可能是整个项目里最不起眼的模块，但它恰恰是数据规范化的地基。很多新手容易忽略它，直接把学院和专业做成两个下拉框塞进表单里，等用户提交后再用字符串存，这是典型的“图省事埋大坑”。

正确设计是：学院表（学院ID、学院名称、学院代码、排序号）和专业表（专业ID、专业名称、专业代码、所属学院ID）。专业表通过学院ID关联学院表，形成一对多关系。管理员可以在后台维护这两个表，提供增删改查和排序功能。

为什么要单独做模块？两个原因。第一，竞赛报名时需要按学院筛选，系统需要统计“XX学院报名多少人”“XX专业获奖人数”这类报表，如果专业名不规范，统计结果就是错的，领导一看数据对不上，整个平台的可信度就崩了。第二，学生注册时需要从下拉框选择学院和专业，如果这些是写死在代码里的，每次专业调整都要发版，非常愚蠢。

实操上我还建议加一个“启用/停用”状态字段，停用的专业在下拉框里不显示，但历史数据不受影响，这样处理学校专业调整时既灵活又安全。

2.5 获奖情况模块：从录入到证书的一体化

获奖情况模块是这个平台最有亮点的部分，也是最能体现项目价值的部分。它的核心功能包括：获奖录入、获奖审核、获奖查询、证书生成与下载。

获奖录入通常由教师操作。一个竞赛结束后，教师在后台选择竞赛场次，然后录入获奖名单。这里的痛点在于获奖名单往往在Excel里，所以一定要提供“批量导入”功能，导入模板至少包含：奖项类别（一等奖/二等奖/三等奖/优秀奖）、学生学号/姓名、团队名称、指导教师、获奖作品名称。批量导入前必须做两件事：第一校验学号是否存在于学生表中，第二去重，避免同一学生在同一竞赛中被录入两次。

获奖结果需要管理员审核，因为教师录入可能存在误操作。审核通过后，获奖数据才对外部可见。这就在“录入”和“对外展示”之间加了一层缓冲，明显减少因为数据错误导致的纠纷。

证书生成是锦上添花的功能，但很受学校欢迎。实现方式不复杂：用一张证书背景图作为底图，把学生姓名、竞赛名称、获奖级别、获奖时间用Java的Graphics2D或Python的PIL/Pillow绘制到图片上，再输出成PDF或PNG。生成时注意两个细节：文本居中计算要按字体实际渲染宽度来算，不要写死坐标；中文需要加载服务器上的中文字体文件，否则会生成乱码方块。

另外，获奖数据建议和学生的综合测评、奖学金评定打通，至少需要支持导出Excel/CSV，这样学校其他系统可以直接导入使用。如果做得好，这个导出功能会是整个平台被高频使用的功能之一。

3. 实操过程与核心环节实现

3.1 技术选型：我为什么推荐Spring Boot + Vue

虽然项目标题没有指定技术栈，但高校竞赛平台这类项目的常见组合是：后端Spring Boot、前端Vue + Element UI、数据库MySQL、文件存储用本地磁盘或OSS、部署用单台服务器即可。

选Spring Boot不是因为“流行”，而是因为它和高校现有系统的兼容性最好。高校信息中心通常已经有其他基于Java技术的系统，运维人员对JVM系技术栈更熟悉，出了问题能有人维护。Vue + Element UI则是后台管理系统的“标准答案”，组件全、资料多、上手快。

如果你的技术栈偏Python，也可以用Django/Flask + Vue，原理完全一样。但说实话，在高校这个场景里，Spring Boot的生态更稳妥，Shiro或Spring Security做权限控制都是现成的轮子。

3.2 数据库表设计：一张ER图说清核心表关系

数据库设计是这个项目最重要的环节，我直接按五个核心模块给出建议表结构。

用户相关表：

• sys_user（用户主表）：id、username（登录名）、password、real_name、role_type（1管理员/2教师/3学生）、status、create_time
• sys_teacher（教师扩展表）：user_id、teacher_no（工号）、college_id、phone、email、title（职称）
• sys_student（学生扩展表）：user_id、student_no（学号）、college_id、major_id、grade（年级）、enroll_date、status

这里我采用的策略是“用户主表+角色扩展表”，而不是把三个角色的字段全塞进一张用户表。原因是三种角色属性差异太大，学生要年级专业，教师要职称学院，管理员没啥特殊字段，硬塞会导致大量字段为空，既浪费存储又增加代码判断的复杂度。

竞赛相关表：

• contest_info（竞赛信息表）：id、title、category_id、contest_level、college_id、teacher_id、begin_time、end_time、signup_start_time、signup_end_time、max_team_members、is_team、status、description、attachment_url
• contest_signup（报名表）：id、contest_id、student_id、team_id、status（待审核/已通过/已拒绝）、signup_time、introduction、work_url

学院专业表：

• sys_college（学院表）：id、name、code、sort_order、status
• sys_major（专业表）：id、name、code、college_id、status

注意专业表的college_id外键指向学院表，学生表再存major_id，不要同时把college_id和major_id都存学生表——都存会导致两个字段的数据可能不一致，一定要通过专业去反查学院。

获奖相关表：

• contest_award（获奖表）：id、contest_id、award_level、award_name、student_id、team_id、teacher_id、work_name、certificate_url、audit_status、audit_time、create_time

创建表的时候，建议所有表都加上create_time、update_time字段，后续排查问题会方便很多。可以用MyBatis Plus的自动填充来维护，不需要每行代码都手写。

3.3 核心接口设计：从登录到获奖查询的完整链路

接口设计遵循RESTful风格，统一返回结构，比如：

{ "code": 200, "message": "操作成功", "data": {} }

这样前端处理逻辑会非常统一，只需要对code做全局拦截即可。

核心接口清单：

• POST /api/auth/login 登录，接收用户名密码，返回token（建议JWT）
• GET /api/auth/info 获取当前登录用户信息和角色权限
• POST /api/admin/teacher 管理员创建教师账号
• PUT /api/admin/teacher/{id} 管理员修改教师信息
• GET /api/teacher/contests 教师查询自己发布的竞赛列表（数据权限过滤）
• POST /api/teacher/contests 教师发布新竞赛
• PUT /api/teacher/contests/{id}/status 竞赛状态变更（提交审核/结束）
• GET /api/student/contests 学生端竞赛列表（只显示报名中的竞赛）
• POST /api/student/contests/{id}/signup 学生报名竞赛
• GET /api/student/contests/{id}/signup/status 查询个人报名状态
• POST /api/teacher/awards/batch-import 教师批量导入获奖名单
• GET /api/student/awards 学生查询自己的获奖列表
• GET /api/admin/stats/college-contest 管理员按学院统计参赛和获奖数据

接口设计原则里，最容易踩坑的是报名接口的“幂等性”。学生可能因为网络卡顿连点了两次报名按钮，没有做幂等控制的话，数据库里就会出现两条重复报名记录。简单解决办法：报名表中给contest_id + student_id加唯一索引，重复插入直接报错，前端捕获后提示“您已报名过该竞赛”。

3.4 报名功能的状态机设计

报名不是“点一下按钮”那么简单。从学生操作视角看，一次完整报名经历的状态依次是：未报名 → 待审核 → 已通过 / 已拒绝。如果竞赛设置了先到先得的名额限制，还需要加一个“已满员”状态。

状态机设计如下：

“已满员”这个状态是需要特别说明的，因为有相当一部分竞赛是有名额限制的，比如只能容纳100支队伍。实现“满员自动截止”不能只靠前端按钮禁用，后端在写入报名记录前必须先执行一条count查询，用事务包裹：SELECT COUNT(*) FOR UPDATE，然后判断是否小于名额上限，再进行INSERT。这里如果不加锁，高并发下就会超录，导致实际报名人数比名额多出几十个，被教务处发现会很尴尬。

3.5 文件上传与附件管理

竞赛平台里涉及的文件类型主要有三类：竞赛章程（PDF/Word）、学生作品（压缩包/PDF）、获奖证书图片（JPG/PNG）。

文件上传功能实现时要注意三个点。

第一，文件大小限制。竞赛章程建议不超过10MB，学生作品建议不超过200MB，超大型作品（比如视频类竞赛）建议单独走网盘分享链接，而不是硬传服务器。

第二，文件名安全。需要对上传文件名做重命名，不能直接用用户上传的原始文件名，防止路径穿越攻击和中文文件名乱码。推荐规则：日期前缀 + UUID + 原始文件扩展名，比如：20250115_8f3a2b9c7d1e4f5a.pdf。

第三，文件存储路径。开发环境存本地磁盘就行，路径建议按竞赛ID分目录，如：/upload/contest/1024/signup/20250115_xxx.pdf。生产环境如果量大了，可以考虑接入OSS/云存储，但高校场景初期单机部署完全够用，别把架构一开始就搞复杂。

3.6 前端页面“抄作业”级别的模块划分

前端用户端建议按以下页面划分：

• 首页/竞赛列表页：展示所有报名中的竞赛，支持按类别、级别、承办学院筛选。
• 竞赛详情页：竞赛基本信息 + 报名按钮 + 已报名人数展示 + 附件下载。
• 个人中心：我的报名记录、我的获奖记录、个人资料维护、密码修改。

管理后台端建议按以下页面划分：

• 控制台：核心指标卡片（竞赛总数、报名总人次、获奖总数、待审核数）。
• 教师管理：教师列表、新增/编辑教师、重置密码、按学院筛选。
• 学生管理：学生列表、审核学生注册、批量导入、按学院/专业筛选。
• 竞赛管理：竞赛列表、发布新竞赛、审核竞赛、竞赛报名名单查看。
• 获奖管理：获奖列表、批量导入获奖、审核获奖、证书管理。
• 学院专业管理：学院列表维护、专业列表维护、启用/停用。
• 系统设置：管理员账号、系统公告、操作日志。

每个页面记住一个原则：列表页要有搜索和分页，详情页要有状态标签，操作按钮要区分权限。做到这三点，后台系统的可用性就不会差。

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

4.1 并发报名导致名额超录，怎么处理

前面提到过，报名超录是最容易在生产环境暴露的问题。我亲自排查过一次：一个竞赛名额上限是100人，开放报名后1分钟内涌入了420个请求，后台数据最终显示有效报名记录107条，超出上限7条。

排查步骤很清晰：先看请求日志确认并发量，再看数据库报名记录发现确实超录，最后定位到代码里那两条业务语句之间没加锁。

解决方式有两种，我推荐第二种。

第一种是用数据库事务隔离级别：把报名流程放到一个事务里，先SELECT COUNT(*) FOR UPDATE锁住竞赛记录行，再判断是否超出名额，最后插入报名记录。缺点是锁表时间较长，高并发下体验会差一些。

第二种是用Redis做原子操作：给每个竞赛维护一个报名计数器，报名前用Redis INCR命令判断是否超出上限，超出直接返回“名额已满”。INCR是原子操作，不会出现并发加出多条的情况。数据库里再通过唯一索引兜底防重。这种方式在高并发下性能更好，还能顺带做一个“当前剩余名额”的实时展示。

4.2 教师端“看不到数据”的权限排查

这个问题的经典场景是：教师登录后台后，竞赛列表是空的，但数据库里明明有该教师名下的竞赛。

排查思路按顺序来：

先检查登录用户ID是否正确，在SQL日志里打印当前教师ID。 再检查查询条件是否带了教师ID过滤，如果SQL是SELECT * FROM contest_info WHERE teacher_id = ?，那就要确认当前这个教师是否真的是竞赛的创建者。 最后检查数据权限拦截器是否生效。如果你用了MyBatis的拦截器做数据权限，很可能因为SQL解析错误把条件过滤掉了，或者多套了一层WHERE把结果全过滤了。

我遇到过一种特别隐蔽的情况：教师A是竞赛的创建者，但后来管理员在教师管理里把教师A的所属学院改了，导致竞赛详情页按学院匹配教师时，结果匹配不上。所以建议竞赛表里不要只存teacher_id，同时冗余存一个college_id，创建时不改，这样即使教师调岗了，历史竞赛还是能对上。

4.3 批量导入学生/获奖数据时的“数据合法性”坑

批量导入功能是高校系统的高频功能，但也是最容易出bug的地方。我整理一个常见问题速查表：

经验之谈：批量导入功能务必生成一个“导入结果详情”，包括成功N条、失败M条、失败原因列表。这样使用者不会觉得“导入失败了但不知道哪里失败”，能大大减少你客服和答疑的工作量。

4.4 证书图片中文显示成方块的解决方案

生成证书时用Java Graphics2D绘制中文，出现“口口口”是最常见的问题。原因很简单：服务器上没有中文字体，或者Graphics2D默认字体不支持中文。

解决办法：把任意一个中文字体文件（比如宋体simsun.ttc或黑体simhei.ttf）放到项目的resources/fonts目录下，然后在代码里通过Font.createFont加载：

InputStream is = new FileInputStream("/opt/fonts/simhei.ttf"); Font font = Font.createFont(Font.TRUETYPE_FONT, is); font = font.deriveFont(Font.PLAIN, 28f); Graphics2D g2d = ...; g2d.setFont(font);

注意两点：第一，Linux服务器默认字体目录可能为空，开发时Windows上有字体不代表生产环境Linux也有，这个坑务必提前处理。第二，证书要转成高清PNG或PDF，生成时设置绘图分辨率为300DPI，否则证书打印出来边缘会有锯齿。

4.5 导出Excel内存溢出的处理

导出获奖名单时，如果一次性把全校几年的获奖数据都查出来塞进内存，然后一行行写Excel，很容易OOM。我在某个项目里就见过导出2万条记录时JVM直接崩溃的情况。

处理方案有两种：

第一种是分页查询，比如每查5000条写一批，用EasyExcel的write的“分批写”能力，边查边写，不把所有数据放内存。

// EasyExcel支持从数据库分批读取再写入 ExcelWriter writer = EasyExcel.write(outputStream, AwardData.class).build(); WriteSheet sheet = EasyExcel.writerSheet("获奖名单").build(); // 分页查询，每页5000条 int page = 1; while (true) { List<AwardData> list = awardMapper.selectPage(page, 5000); if (list.isEmpty()) break; writer.write(list, sheet); page++; } writer.finish();

第二种是直接用数据库的导出功能，比如MySQL的SELECT INTO OUTFILE，生成CSV，然后压缩成zip提供下载。这种方法最快，但要注意文件权限和格式问题。

一般情况下我推荐第一种，兼容性更好，代码结构也清晰。

5. 项目部署与上线运维要点

5.1 服务器与中间件选型

高校竞赛平台的并发量并不高，毕竟参赛学生是有限群体，峰值可能出现在报名开放的前几分钟，但也就是每秒几十个请求的量级。所以不建议一开始就搞微服务、集群、负载均衡那一套，单台8核16G的服务器 + MySQL + Redis + Nginx就完全够用。

Java应用直接打成jar包，用systemd托管进程。配置文件建议用Spring Boot的profile区分开发、测试、生产环境：application-dev.yml、application-prod.yml。敏感信息（数据库密码、Redis密码）不要写死在配置文件里，用环境变量注入。

5.2 上线前必须检查的5件事

项目上线前，我建议你至少过一遍下面的清单：

1. 数据库备份策略：每天凌晨自动备份 + 保留最近7天。高校系统出问题后一般要求能恢复前一天的数据。
2. 日志收集：Java应用日志至少保留30天，建议接入ELK或者简单的日志文件切割方案。排查问题没有日志等于裸奔。
3. 文件目录权限：上传目录在Nginx中禁止执行脚本，否则被传一个jsp/php马就麻烦了。
4. 前后端分离的跨域配置：开发和生产的跨域配置要区分，生产环境建议用Nginx反向代理同源访问，不要开CORS全放行。
5. 教师/学生初始密码策略：上线第一天要通知所有教师修改默认密码，或者干脆设置“首次登录必须修改密码”。

5.3 域名与访问路径规划

高校里通常有统一认证系统，如果竞赛平台能对接学校的统一身份认证（CAS/OAuth2），会大大提升用户体验，学生和教师直接用学号/工号登录，无需单独注册。但对接统一认证涉及学校信息中心的协调，不是项目开发阶段能搞定的，所以一般策略是：平台内置账号体系作为基础，预留对接接口，后续换统一认证时只改登录模块。

如果你要部署在学校的服务器上，建议申请一个子域名，比如：contest.xxx.edu.cn，并配置好HTTPS证书。证书可以用Let's Encrypt免费申请，虽然现在会校验域名所有权，但高校域名通常没问题。HTTP在校园网环境里会显得很不专业，而且浏览器会一直提示不安全，对平台推广影响很不好。

5.4 运维阶段最重要的监控指标

上线不等于结束。有四个指标建议在运营期间持续关注：

• 报名接口的响应时间：如果超过2秒，学生可能以为没提交成功就重复点击，引发并发问题。
• 上传文件接口的成功率：学生提交作品时最怕失败，失败率超过1%就要自查磁盘空间和文件权限。
• 数据库连接池使用率：如果持续飙高，要么是慢SQL太多，要么是连接没释放，建议启用连接池监控。
• 每日活跃用户和报名转化率：竞赛发布后多少人浏览、多少人报名，这个数据可以反馈给教师和教务处，用来评估竞赛的宣传效果。

6. 一些扩展方向：做完核心功能之后还能加什么

如果你的项目时间充裕，或者学校后续提出了新需求，下面这五个方向是高校竞赛平台最常见的衍生功能。

第一，竞赛日历。把所有竞赛的报名时间和比赛时间做成日历视图，学生一眼就能看到“这个月有哪些竞赛可以报、哪个竞赛要截止了”。实现上只需要一个聚合查询接口 + 前端日历组件，但效果拔群。

第二，消息通知。竞赛审核通过、报名审核结果、获奖公布，这些关键节点都给学生发站内信，敏感操作给教师发邮件。用Spring的@Async异步发信，别让通知逻辑拖慢主流程。

第三，竞赛热度排行。按报名人数、浏览量给竞赛加一个热度系数，在首页展示热榜，帮助教师判断竞赛的受欢迎程度，也给后来者选赛提供参考。

第四，二课学分对接。很多高校的学科竞赛与“第二课堂成绩单”挂钩，获奖后可以自动兑换学分。这个需要和学校已有的学工系统对接，一般通过接口推送获奖数据，或者是导出标准格式给对方导入。

第五，移动端适配。高校学生用手机访问网页端频率远高于电脑，Vue项目一定要做响应式适配。如果后续有预算，可以再考虑做一个小程序，但小程序需要额外的审核和部署成本，建议先做好响应式，跑一段时间看真实需求。

从我个人的开发经验来看，竞赛平台这类项目的难点不在于某个单独的技术点，而在于把多个角色的工作流串起来，让信息在系统里顺畅流转，而不是靠微信群和Excel表格人工搬运。我做过好几套类似的系统，最后发现，凡是上线后真正被高频使用的，一定是在流程设计上下了功夫的——教师发布竞赛方便，学生报名路径短，管理员审核有数可依。技术反而是其次，把业务逻辑想透了，代码写起来就很顺了。希望这份复盘对你手头的项目有参考价值。

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