简介这是一套面向高校学科竞赛管理场景的全栈式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_type1管理员/2教师/3学生、status、create_timesys_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_urlcontest_signup报名表id、contest_id、student_id、team_id、status待审核/已通过/已拒绝、signup_time、introduction、work_url学院专业表sys_college学院表id、name、code、sort_order、statussys_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建议JWTGET /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的地方。我整理一个常见问题速查表问题原因解决方案学号前导零丢失Excel将学号识别为数值类型服务端校验学号字段统一按字符串处理导入前检查单元格格式导入的学院/专业匹配不上Excel里写的是专业名称数据库里专业名带“学院”后缀导入时先做名称模糊匹配匹配不到则跳过并生成错误报告重复导入同一个人在同一条记录出现两次导入前先查数据库去重重复数据写入错误日志中文乱码CSV文件编码不是UTF-8统一用UTF-8 BOM格式读CSV或用Excel模板导入POI/EasyExcel经验之谈批量导入功能务必生成一个“导入结果详情”包括成功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) { ListAwardData 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件事项目上线前我建议你至少过一遍下面的清单数据库备份策略每天凌晨自动备份 保留最近7天。高校系统出问题后一般要求能恢复前一天的数据。日志收集Java应用日志至少保留30天建议接入ELK或者简单的日志文件切割方案。排查问题没有日志等于裸奔。文件目录权限上传目录在Nginx中禁止执行脚本否则被传一个jsp/php马就麻烦了。前后端分离的跨域配置开发和生产的跨域配置要区分生产环境建议用Nginx反向代理同源访问不要开CORS全放行。教师/学生初始密码策略上线第一天要通知所有教师修改默认密码或者干脆设置“首次登录必须修改密码”。5.3 域名与访问路径规划高校里通常有统一认证系统如果竞赛平台能对接学校的统一身份认证CAS/OAuth2会大大提升用户体验学生和教师直接用学号/工号登录无需单独注册。但对接统一认证涉及学校信息中心的协调不是项目开发阶段能搞定的所以一般策略是平台内置账号体系作为基础预留对接接口后续换统一认证时只改登录模块。如果你要部署在学校的服务器上建议申请一个子域名比如contest.xxx.edu.cn并配置好HTTPS证书。证书可以用Lets Encrypt免费申请虽然现在会校验域名所有权但高校域名通常没问题。HTTP在校园网环境里会显得很不专业而且浏览器会一直提示不安全对平台推广影响很不好。5.4 运维阶段最重要的监控指标上线不等于结束。有四个指标建议在运营期间持续关注报名接口的响应时间如果超过2秒学生可能以为没提交成功就重复点击引发并发问题。上传文件接口的成功率学生提交作品时最怕失败失败率超过1%就要自查磁盘空间和文件权限。数据库连接池使用率如果持续飙高要么是慢SQL太多要么是连接没释放建议启用连接池监控。每日活跃用户和报名转化率竞赛发布后多少人浏览、多少人报名这个数据可以反馈给教师和教务处用来评估竞赛的宣传效果。6. 一些扩展方向做完核心功能之后还能加什么如果你的项目时间充裕或者学校后续提出了新需求下面这五个方向是高校竞赛平台最常见的衍生功能。第一竞赛日历。把所有竞赛的报名时间和比赛时间做成日历视图学生一眼就能看到“这个月有哪些竞赛可以报、哪个竞赛要截止了”。实现上只需要一个聚合查询接口 前端日历组件但效果拔群。第二消息通知。竞赛审核通过、报名审核结果、获奖公布这些关键节点都给学生发站内信敏感操作给教师发邮件。用Spring的Async异步发信别让通知逻辑拖慢主流程。第三竞赛热度排行。按报名人数、浏览量给竞赛加一个热度系数在首页展示热榜帮助教师判断竞赛的受欢迎程度也给后来者选赛提供参考。第四二课学分对接。很多高校的学科竞赛与“第二课堂成绩单”挂钩获奖后可以自动兑换学分。这个需要和学校已有的学工系统对接一般通过接口推送获奖数据或者是导出标准格式给对方导入。第五移动端适配。高校学生用手机访问网页端频率远高于电脑Vue项目一定要做响应式适配。如果后续有预算可以再考虑做一个小程序但小程序需要额外的审核和部署成本建议先做好响应式跑一段时间看真实需求。从我个人的开发经验来看竞赛平台这类项目的难点不在于某个单独的技术点而在于把多个角色的工作流串起来让信息在系统里顺畅流转而不是靠微信群和Excel表格人工搬运。我做过好几套类似的系统最后发现凡是上线后真正被高频使用的一定是在流程设计上下了功夫的——教师发布竞赛方便学生报名路径短管理员审核有数可依。技术反而是其次把业务逻辑想透了代码写起来就很顺了。希望这份复盘对你手头的项目有参考价值。本文还有配套的精品资源点击获取 高校学科竞赛平台双端架构与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_type1管理员/2教师/3学生、status、create_timesys_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_urlcontest_signup报名表id、contest_id、student_id、team_id、status待审核/已通过/已拒绝、signup_time、introduction、work_url学院专业表sys_college学院表id、name、code、sort_order、statussys_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建议JWTGET /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的地方。我整理一个常见问题速查表问题原因解决方案学号前导零丢失Excel将学号识别为数值类型服务端校验学号字段统一按字符串处理导入前检查单元格格式导入的学院/专业匹配不上Excel里写的是专业名称数据库里专业名带“学院”后缀导入时先做名称模糊匹配匹配不到则跳过并生成错误报告重复导入同一个人在同一条记录出现两次导入前先查数据库去重重复数据写入错误日志中文乱码CSV文件编码不是UTF-8统一用UTF-8 BOM格式读CSV或用Excel模板导入POI/EasyExcel经验之谈批量导入功能务必生成一个“导入结果详情”包括成功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) { ListAwardData 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件事项目上线前我建议你至少过一遍下面的清单数据库备份策略每天凌晨自动备份 保留最近7天。高校系统出问题后一般要求能恢复前一天的数据。日志收集Java应用日志至少保留30天建议接入ELK或者简单的日志文件切割方案。排查问题没有日志等于裸奔。文件目录权限上传目录在Nginx中禁止执行脚本否则被传一个jsp/php马就麻烦了。前后端分离的跨域配置开发和生产的跨域配置要区分生产环境建议用Nginx反向代理同源访问不要开CORS全放行。教师/学生初始密码策略上线第一天要通知所有教师修改默认密码或者干脆设置“首次登录必须修改密码”。5.3 域名与访问路径规划高校里通常有统一认证系统如果竞赛平台能对接学校的统一身份认证CAS/OAuth2会大大提升用户体验学生和教师直接用学号/工号登录无需单独注册。但对接统一认证涉及学校信息中心的协调不是项目开发阶段能搞定的所以一般策略是平台内置账号体系作为基础预留对接接口后续换统一认证时只改登录模块。如果你要部署在学校的服务器上建议申请一个子域名比如contest.xxx.edu.cn并配置好HTTPS证书。证书可以用Lets Encrypt免费申请虽然现在会校验域名所有权但高校域名通常没问题。HTTP在校园网环境里会显得很不专业而且浏览器会一直提示不安全对平台推广影响很不好。5.4 运维阶段最重要的监控指标上线不等于结束。有四个指标建议在运营期间持续关注报名接口的响应时间如果超过2秒学生可能以为没提交成功就重复点击引发并发问题。上传文件接口的成功率学生提交作品时最怕失败失败率超过1%就要自查磁盘空间和文件权限。数据库连接池使用率如果持续飙高要么是慢SQL太多要么是连接没释放建议启用连接池监控。每日活跃用户和报名转化率竞赛发布后多少人浏览、多少人报名这个数据可以反馈给教师和教务处用来评估竞赛的宣传效果。6. 一些扩展方向做完核心功能之后还能加什么如果你的项目时间充裕或者学校后续提出了新需求下面这五个方向是高校竞赛平台最常见的衍生功能。第一竞赛日历。把所有竞赛的报名时间和比赛时间做成日历视图学生一眼就能看到“这个月有哪些竞赛可以报、哪个竞赛要截止了”。实现上只需要一个聚合查询接口 前端日历组件但效果拔群。第二消息通知。竞赛审核通过、报名审核结果、获奖公布这些关键节点都给学生发站内信敏感操作给教师发邮件。用Spring的Async异步发信别让通知逻辑拖慢主流程。第三竞赛热度排行。按报名人数、浏览量给竞赛加一个热度系数在首页展示热榜帮助教师判断竞赛的受欢迎程度也给后来者选赛提供参考。第四二课学分对接。很多高校的学科竞赛与“第二课堂成绩单”挂钩获奖后可以自动兑换学分。这个需要和学校已有的学工系统对接一般通过接口推送获奖数据或者是导出标准格式给对方导入。第五移动端适配。高校学生用手机访问网页端频率远高于电脑Vue项目一定要做响应式适配。如果后续有预算可以再考虑做一个小程序但小程序需要额外的审核和部署成本建议先做好响应式跑一段时间看真实需求。从我个人的开发经验来看竞赛平台这类项目的难点不在于某个单独的技术点而在于把多个角色的工作流串起来让信息在系统里顺畅流转而不是靠微信群和Excel表格人工搬运。我做过好几套类似的系统最后发现凡是上线后真正被高频使用的一定是在流程设计上下了功夫的——教师发布竞赛方便学生报名路径短管理员审核有数可依。技术反而是其次把业务逻辑想透了代码写起来就很顺了。希望这份复盘对你手头的项目有参考价值。本文还有配套的精品资源点击获取