1. 项目概述与核心技术栈拆解1.1 系统定位与业务场景还原学科竞赛管理系统说直白点就是解决“竞赛报名—赛事发布—评审管理—成绩公示”这一整条链路的信息化管理问题。我接触过不少高校和培训机构的竞赛组织场景基本都是这个套路赛事通知靠群消息、报名信息靠问卷星、作品收集靠邮箱、评审打分靠表格、成绩公示靠截图。听着是不是很熟悉这套流程最大问题就是数据分散、状态不透明、追溯困难。管理员每天被“老师我报名了为什么名单上没有我”“作品交了没啊”这类问题反复轰炸精力全耗在重复沟通上了。SpringBootVue这套组合在高校管理类系统中几乎成了事实标准核心原因有两个维度其一是SpringBoot的自动配置和Starter机制让后端服务端开发效率高MyBatis做SQL映射灵活可控适合竞赛这种业务规则多变的场景其二是Vue的前后端分离模式配合Element UI这类组件库能在短时间内搭出界面规范的PC端管理平台。1.2 技术栈选型为什么这么固定JavaMySQLMyBatis这套组合在很多开发者眼里可能显得“不够新潮”但放在学科竞赛管理这个业务场景里其实是深思熟虑过的选择。后端方面SpringBoot 2.x版本稳定性极佳自带内嵌Tomcat一个Jar包就能跑起来部署成本极低。MyBatis相比Hibernate和JPA最大的好处是SQL完全在自己掌控中。竞赛系统的查询逻辑非常复杂——按学院筛选、按竞赛等级国家级/省级/校级筛选、按获奖状态看名单——这些场景下手写SQL配合动态标签性能和灵活性明显优于自动生成的SQL语句。前端选Vue全家桶Vue 2 Vue Router Vuex Element UI大概是目前国内中小型项目使用最成熟的组合了。Vue的双向绑定机制配合Element的表单组件做报名信息填报、审核弹窗、数据表格展示几乎不用造轮子。这套技术栈的招聘市场供给也充足后续有人接手维护也不发愁招不到人。MySQL这里用InnoDB引擎事务支持可靠。竞赛管理涉及报名、审核、成绩录入多个环节一个学生重复报名这种情况如果不能通过唯一索引和事务机制兜底数据就乱套了。MySQL的JSON类型字段还能支持一些动态扩展需求比如不同赛事的补充报名材料不同可以在学生报名表里加一个JSON字段存这些动态信息。提示如果对SpringBoot启动过程不熟悉先理解它“约定优于配置”的核心思路。不需要配置繁琐的XML只需在启动类上用SpringBootApplication一个注解就能自动完成组件扫描、自动配置和属性绑定后面写代码时你会在各个模块反复体会到这种设计带来的便利。2. 数据库设计竞赛管理业务建模的核心思路2.1 数据表的顶层设计概览做管理系统的第一件事不是写代码而是把数据模型理清楚。学科竞赛管理系统的主体数据结构大致可以拆成六个维度用户体系、赛事体系、报名体系、作品体系、评审体系、系统管理。我结合多个实际项目经验推荐设计这八张核心表sys_user用户表存学生、教师、管理员三类角色role字段区分身份competition_info竞赛信息表存赛事基本信息含级别、类型、状态competition_student学生报名表存报名记录及审核状态teacher_info指导教师表存教师信息及所带学生关联work_info作品信息表存提交作品、类型、对应赛事及学生review_record评审记录表存评审老师打分和评语award_info获奖信息表存获奖等级、名次、证书编号sys_log日志表存用户操作记录和登录记录这套表和通用权限系统的区别在于业务表之间的关联关系比较密集。比如报名表competition_student里有一个belong_competition_id外键指向竞赛表有一个student_id外键指向用户表。评审表和作品表之间是通过work_id关联的。设计时要特别在Navicat里把物理外键和索引都建好后期查询性能和维度统计才能真正好用。2.2 关键表的字段设计与约束细节我建议在用户表里使用逻辑删除的del_flag字段而不是物理删除。竞赛系统里用户的参赛记录是重要的历史数据物理删除会直接破坏关联记录的完整性。例如某学生退赛后重新注册如果之前的报名记录被物理删掉了后台查询就会缺少一条关键审计数据。CREATE TABLE competition_student ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, competition_id bigint NOT NULL COMMENT 竞赛ID, student_id bigint NOT NULL COMMENT 学生用户ID, teacher_id bigint DEFAULT NULL COMMENT 指导教师ID, status tinyint NOT NULL DEFAULT 0 COMMENT 审核状态 0待审核 1通过 2驳回, apply_time datetime DEFAULT NULL COMMENT 报名时间, audit_time datetime DEFAULT NULL COMMENT 审核时间, audit_remark varchar(255) DEFAULT NULL COMMENT 审核备注, PRIMARY KEY (id), UNIQUE KEY uk_competition_student (competition_id,student_id), KEY idx_student_id (student_id), KEY idx_competition_id (competition_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT学生竞赛报名表;这里有个易踩的坑报名表一定要加组合唯一索引competition_id student_id。我在开发初期没加这个约束结果测试人员用同一个账号反复点击报名按钮生成了多条记录后台审核人员差点把同一个人当两个参赛者处理。加了这个约束后重复报名直接抛异常到前端统一提示“您已在报名列表中”从数据层面杜绝并发场景下的脏数据。竞赛信息表的竞赛级别字段我建议直接用枚举值0/1/2分别代表校级、省级、国家级存数字比存字符串更节约空间查询效率略高。赛事状态也直接用数字表示0草稿态、1报名中、2评审中、3已结束、4已取消。后续在代码里用枚举类统一管理不要散落字符串魔法值。2.3 数据库事务隔离级别的实际考量竞赛报名的并发峰值其实主要集中在开放报名的头几个小时这时如果有大量学生同时提交需要关注事务一致性问题。MyBatis处理这个场景需要在报名接口的Service方法上添加事务控制。以报名和报送作品同步处理为例如果报名成功但作品信息失败事务必须整体回滚。Override Transactional(rollbackFor Exception.class) public boolean applyCompetition(ApplyRequest request) { // 1. 校验竞赛状态 CompetitionInfo competition competitionMapper.selectById(request.getCompetitionId()); if (competition null || competition.getStatus() ! 1) { throw new BusinessException(竞赛不存在或不在报名时间内); } // 2. 校验报名截止时间 if (LocalDateTime.now().isAfter(competition.getEndTime())) { throw new BusinessException(报名时间已截止); } // 3. 插入报名记录 CompetitionStudent record new CompetitionStudent(); record.setCompetitionId(request.getCompetitionId()); record.setStudentId(request.getStudentId()); record.setStatus(0); // 待审核 record.setApplyTime(LocalDateTime.now()); int insertCount competitionStudentMapper.insert(record); if (insertCount ! 1) { throw new BusinessException(报名失败请稍后重试); } // 4. 记录操作日志 logMapper.insert(new SysLog(APPLY, request.getStudentId())); return true; }Transactional注解加上rollbackFor Exception.class表示出现任何异常都回滚这个细节很多初学者会忽略。我排查过不少线上问题最后发现就是因为某位同事只写了Transactional遇到业务自定义异常时事务并没有回滚数据半成品就留在数据库里了。注意MySQL默认的隔离级别是REPEATABLE READ在这个级别下做报名记录插入是完全够用的。没有必要一定要调整成READ COMMITTED除非你遇到了具体的幻读问题。项目前期把更多的精力花在逻辑设计和查询优化上性价比更高。3. 后端核心功能模块从登录鉴权到业务闭环3.1 JWT认证机制与多角色权限控制管理系统三家角色学生、教师、管理员的权限差异是一个核心设计点。学生只能看到报名入口和成绩查询教师可以通过审核和评分管理员则可以操作系统设置和全部用户数据。我用JWTJSON Web Token实现无状态登录认证结合Spring Security框架做接口权限拦截。JWT方案的最大优势是服务端不必存储会话状态对前后端分离部署场景友好。{ sub: 20240001, role: STUDENT, iat: 1710000000, exp: 1710086400 }Token中封装用户唯一标识和角色信息每次请求携带Token后在拦截器解析、验签、取用户信息。具体分层为三层校验链第一层是Spring Security的全局过滤器判断请求URL是否需要Token第二层是代码里自定义的JWT拦截器做Token合法性校验第三层是在业务层或Controller方法上使用自定义注解RequireRole判断角色权限。角色权限控制的细节在于管理员All权限、教师审核权限、学生仅限本人数据。这里用了一个比较直白的方案学生访问自己的数据时直接从JWT解析出的userId来限定查询范围自己手动拼一个user_id条件在SQL里。这种做法便于追踪和调试避免了AOP切面的过度封装导致排查问题复杂。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } // 放行登录接口和验证码接口 String uri request.getRequestURI(); if (uri.contains(/login) || uri.contains(/captcha)) { return true; } // 获取Token String token request.getHeader(Authorization); if (StringUtils.isBlank(token) || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } // 解析Token Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims null) { throw new BusinessException(401, Token无效); } // 存入ThreadLocal UserContext.setUserId(claims.get(userId, Long.class)); UserContext.setRole(claims.get(role, String.class)); return true; } }关于Token有效期我建议设置成2小时前端在收到401响应时统一跳回登录页。如果某些并发高的场景觉得频繁登录烦可以后续升级为双Token机制短期Refresh Token 长期Access Token但初版做一个短期Token足够覆盖学校内使用的场景。密码存储方面使用BCryptPasswordEncoder加盐加密不用明文存库。改密模块带着旧密码验证再换新密码也是这个环节的常规配套工作。3.2 竞赛发布与报名管理的接口设计竞赛发布是管理员侧的核心功能接口路径设计遵循RESTful规范。赛事发布流程包含基础信息录入、报名时间设置、报名限制设置人数上限、是否允许多赛道、附件上传。发布后赛事进入草稿状态管理员确认无误后点击“上架”前端才会显示报名入口。报名流程的状态机设计很关键。一个完整的生命周期应该是待审核 → 已通过 → 已参赛 → 已获奖以及待审核 → 已驳回带驳回原因。状态流转放在Service层控制禁止跳过状态直接变更。我给你画一下核心的校验逻辑伪码报名前检查赛事状态是否为报名中未开始或已结束直接拒绝检查赛事最大参赛人数实际值是否小于上限检查唯一索引插入记录后发送站内信给对应教师。最终成绩和获奖名单的管理通常由管理员手工录入或评审组导入一条获奖记录包含竞赛ID、学生ID、指导教师ID、获奖级别、证书编号、证书图片URL。证书编号建议由系统自动生成避免用户自填重复生成规则形如AS-2025-00123。3.3 MyBatis动态SQL处理复杂统计查询竞赛系统有个绕不开的需求首页大屏统计。每年某个学院一共报名多少人今年校级奖项发了多少个哪些竞赛参与度最高这些统计如果每个指标都单独写一条常规查询语句开发效率和执行性能都会大打折扣。用MyBatis的 和 动态标签组织查询条件既能应对筛选条件不固定的场景也能把这些复杂逻辑推到数据库侧利用索引快速度量。select idselectStatisticsByConditions resultTypejava.util.Map SELECT c.competition_name AS competitionName, COUNT(cs.id) AS applyCount, COUNT(CASE WHEN cs.status 1 THEN 1 END) AS approvedCount, COUNT(DISTINCT cs.student_id) AS uniqueStudentCount FROM competition_student cs LEFT JOIN competition_info c ON cs.competition_id c.id where if testcompetitionType ! null and competitionType ! AND c.type #{competitionType} /if if teststartTime ! null AND cs.apply_time gt; #{startTime} /if if testendTime ! null AND cs.apply_time lt; #{endTime} /if /where GROUP BY c.competition_name /select这种统计SQL里最容易翻车的地方是时间比较符号。在XML中我需要写而不能直接用否则XML解析阶段直接报错。如果项目里MyBatis版本允许建议尽量用参数传递日期避免拼接字符串引起时区问题。统计结果用Map接收前端拿到JSON直接渲染省去额外定义DTO类的功夫。4. 前端Vue页面实现与交互细节4.1 路由设计、状态管理与目录结构规范前端项目的目录结构我是这样组织的整体思路是按模块归类而不是按文件类型归类便于多人协作时各管一摊。src/ ├── api/ # 接口请求封装按业务模块拆分 │ ├── auth.js │ ├── competition.js │ ├── student.js │ └── teacher.js ├── views/ # 页面视图 │ ├── login/index.vue │ ├── admin/competition/list.vue │ ├── admin/competition/edit.vue │ ├── student/apply/index.vue │ └── teacher/review/index.vue ├── router/index.js # 路由配置 ├── store/ # Vuex模块 └── utils/ # 请求封装、公共方法路由设计中动态路由是一个值得注意的点导航守卫根据用户角色动态注入菜单表教师登录后可以访问审核和评分页面学生登录后只能看到报名和成绩页面。// 路由守卫核心逻辑 router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (!token to.path ! /login) { next(/login); return; } const userRole store.getters.role; if (to.meta.roles !to.meta.roles.includes(userRole)) { Message.error(无权限访问该页面); next(/403); return; } next(); })另一处常见问题是前端接口请求封装。我在utils/request.js里基于axios封装了一层统一处理BaseURL、请求头注入Token、错误码响应拦截所有接口模块引用的都是封装后的实例。后端接口返回code字段约定为200成功、401未登录、403无权限、500服务器错误前端在响应拦截器里对code统一弹提示这样业务代码里就不用重复处理异常了。4.2 Element UI套件实现报名表单与审核工作台报名表单是学生接触最频繁的面字段设计原则是“能选的不让填能自动带出的不手动填”。竞赛名称加载后下拉选择报名时自动带出当前用户姓名学号且不可编辑指导教师从可选列表中选择作品简介和成员说明用textarea输入。表单校验用Element的rules配置手机号验证规则用正则作品文件名校验后缀格式。审核工作台是教师的日常主界面。数据表格需要展示报名人信息、赛事名称、报名时间、当前状态操作列包含“通过”“驳回”两个按钮。驳回时弹出对话框要求填写原因原因保存到audit_remark字段里。前端这里有个容易忽视的细节当数据量大时表格连同分页器的数据请求一定要带上页码和条数参数后端用PageHelper分页插件来做LIMIT拼接。Element的el-pagination组件贴一个完整示例方便你直接抄el-pagination background layouttotal, sizes, prev, pager, next, jumper :totaltotal :page-sizes[10, 20, 50] :current-pagequeryParams.pageNum :page-sizequeryParams.pageSize size-changehandleSizeChange current-changehandleCurrentChange /el-pagination4.3 数据可视化竞赛统计看板与图表构建管理首页我建议加一个统计面板直观展示各学院报名人数排行、各赛事参与热度、赛事审核通过率。ECharts在这里是首选它生态成熟文档完善Vue项目接入成本低。先从后端统计数据接口拿到分类汇总数组再用ECharts的柱状图和饼图渲染。柱状图的X轴是学院名称Y轴是报名人数饼图展示赛事类型分布。调试阶段最容易出现的问题是ECharts在容器未加载完成时实例化导致高度为0解法是在Vue的mounted钩子后使用$nextTick或在watch指定数据源后触发init方法。initCharts() { this.$nextTick(() { const chartDom this.$refs.barChart; if (this.chart) { this.chart.dispose(); } this.chart echarts.init(chartDom); this.chart.setOption(barOption); }); }这里resize监听也值得处理浏览器窗口变化时图表需要自适应。在mounted中注册window resize监听函数beforeDestroy中移除监听防止内存泄漏。这个细节很多教程不会写但上线高峰期页面卡死时你就明白为什么了。5. 文件上传与数据导出竞赛系统的高频需求5.1 作品材料上传方案的落地实现竞赛作品通常包含多个文件论文PDF、演示视频、源代码压缩包等。我这里的处理办法是本地磁盘存储文件记录表只存相对路径和URL地址。考虑到后续运维简便本地存储远优于把文件直接塞数据库Media类型字段读取效率低数据库一般也不承担文件存储职责。PostMapping(/upload) public Result upload(MultipartFile file, HttpServletRequest request) { if (file.isEmpty()) { return Result.error(请选择文件); } String originalFilename file.getOriginalFilename(); long maxSize 100 * 1024 * 1024L; // 100MB上限 if (file.getSize() maxSize) { return Result.error(文件大小不能超过100MB); } // 防止上传危险文件类型 String ext FilenameUtils.getExtension(originalFilename); if (!allowedExtSet.contains(ext.toLowerCase())) { return Result.error(不支持的文件类型); } // 按日期分目录存储 String datePath new SimpleDateFormat(yyyy/MM/dd).format(new Date()); String realPath uploadRootPath / datePath; File dir new File(realPath); if (!dir.exists()) { dir.mkdirs(); } // 使用UUID重命名避免文件名冲突 String newName UUID.randomUUID().toString().replace(-, ) . ext; file.transferTo(new File(realPath / newName)); String url /upload/ datePath / newName; return Result.success(url); }文件名用UUID重命名是常规做法防止两个学生上传同名文件相互覆盖。文件类型白名单校验建议放在后端而不是前端前端校验很容易被绕过。我见过某些系统只在前端写accept属性后台上传脚本照样能传恶意文件安全隐患很大。补充一句如果把系统部署到云服务器磁盘空间有限建议接入OSS对象存储服务后端只需返回预签名URL。这个改造不复杂Main逻辑是把文件从服务端转发到OSS服务再存储访问链接。初期本地存储足够了。5.2 Excel导出获奖名单的完整流程指导教师经常需要导出名单用于盖章、存档或汇总上报。后端用Hutool的ExcelWriter工具类两行代码就能操作Sheet。GetMapping(/export) public void exportAwardList(HttpServletResponse response) throws IOException { ListAwardVO awardList awardService.selectAwardList(queryParams); ExcelWriter writer ExcelUtil.getWriter(true, 获奖名单); // 自定义列名 writer.addHeaderAlias(studentName, 学生姓名); writer.addHeaderAlias(competitionName, 竞赛名称); writer.addHeaderAlias(awardLevel, 获奖等级); writer.addHeaderAlias(certificateNo, 证书编号); writer.addHeaderAlias(teacherName, 指导教师); writer.write(awardList, true); response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;charsetutf-8); response.setHeader(Content-Disposition, attachment;filename URLEncoder.encode(获奖名单.xlsx, UTF-8)); writer.flush(response.getOutputStream(), true); writer.close(); }导出这块踩过最典型的坑是中文文件名。直接设置Content-Disposition参数会导致火狐浏览器出现乱码必须使用URLEncoder编码后拼到header里。还有一个细节是前端需要以blob方式接收导出文件不能走普通JSON解析否则会出现文件内容被浏览器当文本打开且下载失败。6. 部署上线实践从本地跑通到服务器落地6.1 环境准备与本地联调全流程很多新手在本地联调阶段就被卡住了最常见的坑是前后端端口跨域问题。SpringBoot后端端口配置在application.yml里这里贴一份环境配置的核心参数示例spring: datasource: url: jdbc:mysql://localhost:3306/competition_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 server: port: 8080前端项目开发环境跨域问题我通常建议在Vue配置里开启代理转发vite.config.jsVite或vue.config.jsVue CLI都可以实现。核心机制是前端请求走相对路径如/apiVite开发服务器收到请求后帮我们把/api前缀的请求转发给后端8080端口从而绕过浏览器同源策略限制。生产环境则可以用Nginx做反向代理同时托管前端静态文件和后端接口转发。6.2 生产环境部署流程手册生产环境我推荐一套简单稳定的方案Nginx Jar包 MySQL。前端项目执行npm run build生成dist静态目录交给Nginx托管后端直接打成Jar包用systemd守护进程方式运行。我这里写一份部署命令速查列表# 构建前端产物 npm run build # 打包后端 mvn clean package -DskipTests # 上传jar包后启动 java -jar competition-system.jar --spring.profiles.activeprod # 设置开机自启以systemd注册服务为例 sudo cp competition-system.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable competition-system sudo systemctl start competition-system生产环境数据库地址和密码请署到独立的prod配置文件中不要直接写死在application.yml。密码用Jasypt加密组件混淆或者至少用环境变量注入方式读取不要明文提交到代码仓库。这一条我在自查清单里反复核对过炸过的项目基本都是在密码管理上偷懒。6.3 上线前的数据备份与安全加固竞赛系统上线前数据库备份策略是底线工作。我习惯部署一个每天凌晨的cron任务通过mysqldump备份全库数据到独立磁盘或备份目录备份文件保留近30天。#!/bin/bash BACKUP_DIR/data/backup/mysql DATE$(date %Y%m%d%H%M) DB_NAMEcompetition_db DB_USERroot DB_PASSWORDyourpassword mkdir -p $BACKUP_DIR mysqldump -u$DB_USER -p$DB_PASSWORD $DB_NAME $BACKUP_DIR/${DB_NAME}_${DATE}.sql find $BACKUP_DIR -mtime 30 -name *.sql -delete如果你使用云服务器建议额外配置云厂商的自动化快照策略每周做一次磁盘快照。这样即使人工误操作删数据也能从快照层面恢复形成双保险。安全加固上MySQL不要用默认端口3306暴露公网反向代理层加上IP白名单限制后台管理入口基本可以抵御大部分扫描攻击。7. 常见问题排查与性能调优实录7.1 后端常见异常问题速查表我把这类项目中最常遇到的问题整理成一张速查表实际排查效率能提升不少错误现象可能原因排查命令/手段前端报跨域浏览器Console红色CORS后端未配置跨域过滤器或配置顺序不对检查WebConfig中CorsRegistry是否正确注册数据库密码错误报Access denied环境变量未生效或密码配置多空格SpringBoot启动日志打印明文检查用户登录成功但跳转后刷新掉登录态前端路由守卫未处理Token持久化查看store初始化逻辑是否每次都读localStorage上传图片后无法访问404Nginx未配置upload路径静态资源映射location /upload { alias 磁盘路径; }导出Excel中文乱码Content-Disposition没有URL编码使用URLEncoder.encode查询慢且大表全扫描未建索引或索引未命中EXPLAIN sql语句看type列7.2 性能优化分页查询索引优化实践随着参赛记录增多分页查询性能会逐渐下降最常见的问题在limit做深分页时偏移量过大导致扫描大量无关数据。比如limit 100000, 20这种情况MySQL会先把前10万条全读出来再丢弃产生大量无谓的磁盘IO。优化方案是将分页条件改造为基于上一页最大主键的游标翻页-- 传统深分页效率低 SELECT * FROM competition_student ORDER BY id DESC LIMIT 100000, 20; -- 游标翻页效率高 SELECT * FROM competition_student WHERE id #{lastId} ORDER BY id DESC LIMIT 20;这类优化改动很小但数据量超过20万条时性能差异非常明显。另外一个前端注意事项是表格不要一次性加载全部数据永远要求用户设置分页大小并传pageNum/pageSize参数这既是性能手段也是接口设计规范。7.3 前端内存泄漏与白屏问题排查还有一个我反复遇见的坑Element UI的Dialog或el-table在循环渲染且数据频繁更新时如果ECharts实例没有正确销毁会逐步占满浏览器内存导致白屏卡顿。排查方向是用Chrome DevTools的Profiler记录堆内存变化调用GC后观察Detached节点是否残留。操作建议是动态弹窗关闭时在destroyed钩子里clear组件实例ECharts在beforeDestroy中dispose全局Window事件监听器在destroyed时removeEventListener。这些都属于“看不见但会杀人的细节”上线前最好用性能工具跑一遍。排查白屏问题的优先级建议先看Network请求状态码和返回内容再检查Console报错和JavaScript执行时序最后排查数据渲染异常或组件重复渲染引起的Effect错误从服务接口到前端渲染逐层排查。8. 系统扩展方向与我的实操心得8.1 功能扩展与多端适配方向初版系统正常运行后如果你的实际使用场景更复杂可以沿着几个方向扩展。其一是接入消息通知模块把站内信、邮件、短信通知做成统一的消息中心报名审核通过、赛事开启提醒等事件都能自动推送。其二是增加赛事流程管理的自定义表单配置允许管理员拖拽定义报名表格字段——这个方向工作量大但通用性很强。其三是增加证书在线生成与下载功能通过模板渲染生成电子证书省去手工盖章扫描的流程。如果从技术架构角度看你可以把整个系统按模块拆分出独立的微服务认证服务、竞赛服务、文件服务也可以引入工作流引擎来处理复杂的多级评审流程。但对高校内部管理系统来说单体架构在绝大多数情况下已经足够盲目上微服务反而增加运维负担不建议初期就大动干戈。8.2 从需求理解到落地的几点个人经验做这类管理系统这么多年我最深的体会是技术选型永远是简单场景的第一表达不要为炫技引入复杂框架。报名审核并发不高的业务引入消息队列中间件只会拖垮交付节奏团队成员只会写SQL的时候硬推到NoSQL数据库完全是灾难。第二个体会是在动手编码之前一定要把数据库的表结构和状态机梳理清楚这一点花掉的时间永远是最值得的投资。我见过太多项目因为上线前改字段、改状态导致联调延期的情况而这些问题的根子几乎都出在数据模型设计初期没想清楚。第三点是项目交付后务必写一份简要部署文档和数据库初始化脚本交给接手人时价值比想象中大得多。很多项目换人维护后一脸懵通常就是因为技术文档缺失只能靠读源码摸索。9. 项目源码结构导览与二次开发建议9.1 后端与前端的关键代码位置指引对于想拿这套结构做二次开发的开发者知道关键代码藏在哪个包里是最有价值的。后端包结构建议如下分布com.example.competition/ ├── config/ # 跨域配置、MyBatis配置、文件上传配置 ├── controller/ # REST接口层 │ ├── AuthController.java │ ├── CompetitionController.java │ ├── StudentApplyController.java │ └── ReviewController.java ├── service/ # 业务逻辑层 │ ├── impl/ │ └── service接口 ├── mapper/ # MyBatis Mapper接口 ├── entity/ # 数据库实体 ├── vo/ # 视图对象 ├── common/ # 统一返回Result、异常处理、常量枚举 └── utils/ # JwtUtil、ExcelUtil等工具类这里common包里Result类是所有接口的统一返回模板格式为code、message、data三个字段。前端axios拦截器中对非200 code统一处理这个规范要跟后端同事约定清楚不然每个人写一套返回格式联调时互相折磨。9.2 二次开发的建议顺序如果你想不改变现有主流程只新增模块建议先从数据库建表开始然后写实体、Mapper接口和XML、Service、Controller最后写前端页面和接口封装。这个顺序是瀑布式的每一层依赖前一层按此推进基本不会发生返工。如果要调整审核流程比如增加二级审核最稳妥的方式是给报名表增加一个audit_level字段然后复用同一个审核接口传入当前审核级别。不建议新开一张审核历史表出来因为这会牵扯到前端大量联动改动复杂度成倍增长。9.3 最后分享一个小技巧开发联调时如果发现某些模糊查询带条件后查询结果异常第一步先检查MyBatis XML中 标签的test语句中对象属性名拼写这个错误往往不会在SQL日志直接暴露行号而是会变成不合适的过滤条件返回空数据。日志级别至少要在开发环境把mapper包的日志设置为DEBUG这样能直接打印完整SQL和参数。这个动作能解决联调阶段80%以上的“我怎么查不到数据”类疑问。实际操作中我还会在本地准备一个可以随时重置的测试数据库每次改动表结构后自动执行SQL迁移脚本保持表结构文档和实际库同步——这套协作习惯让我和同事在长期迭代中省去了大量同步沟通成本也算是在这个项目之外沉淀下来的一个额外心得吧。如果你正打算做类似的管理系统尤其是在校生做毕业设计或者课程项目这套SpringBootVueMySQLMyBatis的架构足够撑起一个完整可靠、能演示、能部署的中型管理系统。按我上面梳理的模块顺序逐步实现从数据建模到前端页面从本地联调到上线部署是一条已经被大量项目验证过的稳妥路线。 
长河君 · 2026/10/21 2:01:20 · 阅读 1.2k SpringBoot+Vue学科竞赛管理系统实战：从数据库设计到部署上线
1. 项目概述与核心技术栈拆解1.1 系统定位与业务场景还原学科竞赛管理系统说直白点就是解决“竞赛报名—赛事发布—评审管理—成绩公示”这一整条链路的信息化管理问题。我接触过不少高校和培训机构的竞赛组织场景基本都是这个套路赛事通知靠群消息、报名信息靠问卷星、作品收集靠邮箱、评审打分靠表格、成绩公示靠截图。听着是不是很熟悉这套流程最大问题就是数据分散、状态不透明、追溯困难。管理员每天被“老师我报名了为什么名单上没有我”“作品交了没啊”这类问题反复轰炸精力全耗在重复沟通上了。SpringBootVue这套组合在高校管理类系统中几乎成了事实标准核心原因有两个维度其一是SpringBoot的自动配置和Starter机制让后端服务端开发效率高MyBatis做SQL映射灵活可控适合竞赛这种业务规则多变的场景其二是Vue的前后端分离模式配合Element UI这类组件库能在短时间内搭出界面规范的PC端管理平台。1.2 技术栈选型为什么这么固定JavaMySQLMyBatis这套组合在很多开发者眼里可能显得“不够新潮”但放在学科竞赛管理这个业务场景里其实是深思熟虑过的选择。后端方面SpringBoot 2.x版本稳定性极佳自带内嵌Tomcat一个Jar包就能跑起来部署成本极低。MyBatis相比Hibernate和JPA最大的好处是SQL完全在自己掌控中。竞赛系统的查询逻辑非常复杂——按学院筛选、按竞赛等级国家级/省级/校级筛选、按获奖状态看名单——这些场景下手写SQL配合动态标签性能和灵活性明显优于自动生成的SQL语句。前端选Vue全家桶Vue 2 Vue Router Vuex Element UI大概是目前国内中小型项目使用最成熟的组合了。Vue的双向绑定机制配合Element的表单组件做报名信息填报、审核弹窗、数据表格展示几乎不用造轮子。这套技术栈的招聘市场供给也充足后续有人接手维护也不发愁招不到人。MySQL这里用InnoDB引擎事务支持可靠。竞赛管理涉及报名、审核、成绩录入多个环节一个学生重复报名这种情况如果不能通过唯一索引和事务机制兜底数据就乱套了。MySQL的JSON类型字段还能支持一些动态扩展需求比如不同赛事的补充报名材料不同可以在学生报名表里加一个JSON字段存这些动态信息。提示如果对SpringBoot启动过程不熟悉先理解它“约定优于配置”的核心思路。不需要配置繁琐的XML只需在启动类上用SpringBootApplication一个注解就能自动完成组件扫描、自动配置和属性绑定后面写代码时你会在各个模块反复体会到这种设计带来的便利。2. 数据库设计竞赛管理业务建模的核心思路2.1 数据表的顶层设计概览做管理系统的第一件事不是写代码而是把数据模型理清楚。学科竞赛管理系统的主体数据结构大致可以拆成六个维度用户体系、赛事体系、报名体系、作品体系、评审体系、系统管理。我结合多个实际项目经验推荐设计这八张核心表sys_user用户表存学生、教师、管理员三类角色role字段区分身份competition_info竞赛信息表存赛事基本信息含级别、类型、状态competition_student学生报名表存报名记录及审核状态teacher_info指导教师表存教师信息及所带学生关联work_info作品信息表存提交作品、类型、对应赛事及学生review_record评审记录表存评审老师打分和评语award_info获奖信息表存获奖等级、名次、证书编号sys_log日志表存用户操作记录和登录记录这套表和通用权限系统的区别在于业务表之间的关联关系比较密集。比如报名表competition_student里有一个belong_competition_id外键指向竞赛表有一个student_id外键指向用户表。评审表和作品表之间是通过work_id关联的。设计时要特别在Navicat里把物理外键和索引都建好后期查询性能和维度统计才能真正好用。2.2 关键表的字段设计与约束细节我建议在用户表里使用逻辑删除的del_flag字段而不是物理删除。竞赛系统里用户的参赛记录是重要的历史数据物理删除会直接破坏关联记录的完整性。例如某学生退赛后重新注册如果之前的报名记录被物理删掉了后台查询就会缺少一条关键审计数据。CREATE TABLE competition_student ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, competition_id bigint NOT NULL COMMENT 竞赛ID, student_id bigint NOT NULL COMMENT 学生用户ID, teacher_id bigint DEFAULT NULL COMMENT 指导教师ID, status tinyint NOT NULL DEFAULT 0 COMMENT 审核状态 0待审核 1通过 2驳回, apply_time datetime DEFAULT NULL COMMENT 报名时间, audit_time datetime DEFAULT NULL COMMENT 审核时间, audit_remark varchar(255) DEFAULT NULL COMMENT 审核备注, PRIMARY KEY (id), UNIQUE KEY uk_competition_student (competition_id,student_id), KEY idx_student_id (student_id), KEY idx_competition_id (competition_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT学生竞赛报名表;这里有个易踩的坑报名表一定要加组合唯一索引competition_id student_id。我在开发初期没加这个约束结果测试人员用同一个账号反复点击报名按钮生成了多条记录后台审核人员差点把同一个人当两个参赛者处理。加了这个约束后重复报名直接抛异常到前端统一提示“您已在报名列表中”从数据层面杜绝并发场景下的脏数据。竞赛信息表的竞赛级别字段我建议直接用枚举值0/1/2分别代表校级、省级、国家级存数字比存字符串更节约空间查询效率略高。赛事状态也直接用数字表示0草稿态、1报名中、2评审中、3已结束、4已取消。后续在代码里用枚举类统一管理不要散落字符串魔法值。2.3 数据库事务隔离级别的实际考量竞赛报名的并发峰值其实主要集中在开放报名的头几个小时这时如果有大量学生同时提交需要关注事务一致性问题。MyBatis处理这个场景需要在报名接口的Service方法上添加事务控制。以报名和报送作品同步处理为例如果报名成功但作品信息失败事务必须整体回滚。Override Transactional(rollbackFor Exception.class) public boolean applyCompetition(ApplyRequest request) { // 1. 校验竞赛状态 CompetitionInfo competition competitionMapper.selectById(request.getCompetitionId()); if (competition null || competition.getStatus() ! 1) { throw new BusinessException(竞赛不存在或不在报名时间内); } // 2. 校验报名截止时间 if (LocalDateTime.now().isAfter(competition.getEndTime())) { throw new BusinessException(报名时间已截止); } // 3. 插入报名记录 CompetitionStudent record new CompetitionStudent(); record.setCompetitionId(request.getCompetitionId()); record.setStudentId(request.getStudentId()); record.setStatus(0); // 待审核 record.setApplyTime(LocalDateTime.now()); int insertCount competitionStudentMapper.insert(record); if (insertCount ! 1) { throw new BusinessException(报名失败请稍后重试); } // 4. 记录操作日志 logMapper.insert(new SysLog(APPLY, request.getStudentId())); return true; }Transactional注解加上rollbackFor Exception.class表示出现任何异常都回滚这个细节很多初学者会忽略。我排查过不少线上问题最后发现就是因为某位同事只写了Transactional遇到业务自定义异常时事务并没有回滚数据半成品就留在数据库里了。注意MySQL默认的隔离级别是REPEATABLE READ在这个级别下做报名记录插入是完全够用的。没有必要一定要调整成READ COMMITTED除非你遇到了具体的幻读问题。项目前期把更多的精力花在逻辑设计和查询优化上性价比更高。3. 后端核心功能模块从登录鉴权到业务闭环3.1 JWT认证机制与多角色权限控制管理系统三家角色学生、教师、管理员的权限差异是一个核心设计点。学生只能看到报名入口和成绩查询教师可以通过审核和评分管理员则可以操作系统设置和全部用户数据。我用JWTJSON Web Token实现无状态登录认证结合Spring Security框架做接口权限拦截。JWT方案的最大优势是服务端不必存储会话状态对前后端分离部署场景友好。{ sub: 20240001, role: STUDENT, iat: 1710000000, exp: 1710086400 }Token中封装用户唯一标识和角色信息每次请求携带Token后在拦截器解析、验签、取用户信息。具体分层为三层校验链第一层是Spring Security的全局过滤器判断请求URL是否需要Token第二层是代码里自定义的JWT拦截器做Token合法性校验第三层是在业务层或Controller方法上使用自定义注解RequireRole判断角色权限。角色权限控制的细节在于管理员All权限、教师审核权限、学生仅限本人数据。这里用了一个比较直白的方案学生访问自己的数据时直接从JWT解析出的userId来限定查询范围自己手动拼一个user_id条件在SQL里。这种做法便于追踪和调试避免了AOP切面的过度封装导致排查问题复杂。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } // 放行登录接口和验证码接口 String uri request.getRequestURI(); if (uri.contains(/login) || uri.contains(/captcha)) { return true; } // 获取Token String token request.getHeader(Authorization); if (StringUtils.isBlank(token) || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } // 解析Token Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims null) { throw new BusinessException(401, Token无效); } // 存入ThreadLocal UserContext.setUserId(claims.get(userId, Long.class)); UserContext.setRole(claims.get(role, String.class)); return true; } }关于Token有效期我建议设置成2小时前端在收到401响应时统一跳回登录页。如果某些并发高的场景觉得频繁登录烦可以后续升级为双Token机制短期Refresh Token 长期Access Token但初版做一个短期Token足够覆盖学校内使用的场景。密码存储方面使用BCryptPasswordEncoder加盐加密不用明文存库。改密模块带着旧密码验证再换新密码也是这个环节的常规配套工作。3.2 竞赛发布与报名管理的接口设计竞赛发布是管理员侧的核心功能接口路径设计遵循RESTful规范。赛事发布流程包含基础信息录入、报名时间设置、报名限制设置人数上限、是否允许多赛道、附件上传。发布后赛事进入草稿状态管理员确认无误后点击“上架”前端才会显示报名入口。报名流程的状态机设计很关键。一个完整的生命周期应该是待审核 → 已通过 → 已参赛 → 已获奖以及待审核 → 已驳回带驳回原因。状态流转放在Service层控制禁止跳过状态直接变更。我给你画一下核心的校验逻辑伪码报名前检查赛事状态是否为报名中未开始或已结束直接拒绝检查赛事最大参赛人数实际值是否小于上限检查唯一索引插入记录后发送站内信给对应教师。最终成绩和获奖名单的管理通常由管理员手工录入或评审组导入一条获奖记录包含竞赛ID、学生ID、指导教师ID、获奖级别、证书编号、证书图片URL。证书编号建议由系统自动生成避免用户自填重复生成规则形如AS-2025-00123。3.3 MyBatis动态SQL处理复杂统计查询竞赛系统有个绕不开的需求首页大屏统计。每年某个学院一共报名多少人今年校级奖项发了多少个哪些竞赛参与度最高这些统计如果每个指标都单独写一条常规查询语句开发效率和执行性能都会大打折扣。用MyBatis的 和 动态标签组织查询条件既能应对筛选条件不固定的场景也能把这些复杂逻辑推到数据库侧利用索引快速度量。select idselectStatisticsByConditions resultTypejava.util.Map SELECT c.competition_name AS competitionName, COUNT(cs.id) AS applyCount, COUNT(CASE WHEN cs.status 1 THEN 1 END) AS approvedCount, COUNT(DISTINCT cs.student_id) AS uniqueStudentCount FROM competition_student cs LEFT JOIN competition_info c ON cs.competition_id c.id where if testcompetitionType ! null and competitionType ! AND c.type #{competitionType} /if if teststartTime ! null AND cs.apply_time gt; #{startTime} /if if testendTime ! null AND cs.apply_time lt; #{endTime} /if /where GROUP BY c.competition_name /select这种统计SQL里最容易翻车的地方是时间比较符号。在XML中我需要写而不能直接用否则XML解析阶段直接报错。如果项目里MyBatis版本允许建议尽量用参数传递日期避免拼接字符串引起时区问题。统计结果用Map接收前端拿到JSON直接渲染省去额外定义DTO类的功夫。4. 前端Vue页面实现与交互细节4.1 路由设计、状态管理与目录结构规范前端项目的目录结构我是这样组织的整体思路是按模块归类而不是按文件类型归类便于多人协作时各管一摊。src/ ├── api/ # 接口请求封装按业务模块拆分 │ ├── auth.js │ ├── competition.js │ ├── student.js │ └── teacher.js ├── views/ # 页面视图 │ ├── login/index.vue │ ├── admin/competition/list.vue │ ├── admin/competition/edit.vue │ ├── student/apply/index.vue │ └── teacher/review/index.vue ├── router/index.js # 路由配置 ├── store/ # Vuex模块 └── utils/ # 请求封装、公共方法路由设计中动态路由是一个值得注意的点导航守卫根据用户角色动态注入菜单表教师登录后可以访问审核和评分页面学生登录后只能看到报名和成绩页面。// 路由守卫核心逻辑 router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (!token to.path ! /login) { next(/login); return; } const userRole store.getters.role; if (to.meta.roles !to.meta.roles.includes(userRole)) { Message.error(无权限访问该页面); next(/403); return; } next(); })另一处常见问题是前端接口请求封装。我在utils/request.js里基于axios封装了一层统一处理BaseURL、请求头注入Token、错误码响应拦截所有接口模块引用的都是封装后的实例。后端接口返回code字段约定为200成功、401未登录、403无权限、500服务器错误前端在响应拦截器里对code统一弹提示这样业务代码里就不用重复处理异常了。4.2 Element UI套件实现报名表单与审核工作台报名表单是学生接触最频繁的面字段设计原则是“能选的不让填能自动带出的不手动填”。竞赛名称加载后下拉选择报名时自动带出当前用户姓名学号且不可编辑指导教师从可选列表中选择作品简介和成员说明用textarea输入。表单校验用Element的rules配置手机号验证规则用正则作品文件名校验后缀格式。审核工作台是教师的日常主界面。数据表格需要展示报名人信息、赛事名称、报名时间、当前状态操作列包含“通过”“驳回”两个按钮。驳回时弹出对话框要求填写原因原因保存到audit_remark字段里。前端这里有个容易忽视的细节当数据量大时表格连同分页器的数据请求一定要带上页码和条数参数后端用PageHelper分页插件来做LIMIT拼接。Element的el-pagination组件贴一个完整示例方便你直接抄el-pagination background layouttotal, sizes, prev, pager, next, jumper :totaltotal :page-sizes[10, 20, 50] :current-pagequeryParams.pageNum :page-sizequeryParams.pageSize size-changehandleSizeChange current-changehandleCurrentChange /el-pagination4.3 数据可视化竞赛统计看板与图表构建管理首页我建议加一个统计面板直观展示各学院报名人数排行、各赛事参与热度、赛事审核通过率。ECharts在这里是首选它生态成熟文档完善Vue项目接入成本低。先从后端统计数据接口拿到分类汇总数组再用ECharts的柱状图和饼图渲染。柱状图的X轴是学院名称Y轴是报名人数饼图展示赛事类型分布。调试阶段最容易出现的问题是ECharts在容器未加载完成时实例化导致高度为0解法是在Vue的mounted钩子后使用$nextTick或在watch指定数据源后触发init方法。initCharts() { this.$nextTick(() { const chartDom this.$refs.barChart; if (this.chart) { this.chart.dispose(); } this.chart echarts.init(chartDom); this.chart.setOption(barOption); }); }这里resize监听也值得处理浏览器窗口变化时图表需要自适应。在mounted中注册window resize监听函数beforeDestroy中移除监听防止内存泄漏。这个细节很多教程不会写但上线高峰期页面卡死时你就明白为什么了。5. 文件上传与数据导出竞赛系统的高频需求5.1 作品材料上传方案的落地实现竞赛作品通常包含多个文件论文PDF、演示视频、源代码压缩包等。我这里的处理办法是本地磁盘存储文件记录表只存相对路径和URL地址。考虑到后续运维简便本地存储远优于把文件直接塞数据库Media类型字段读取效率低数据库一般也不承担文件存储职责。PostMapping(/upload) public Result upload(MultipartFile file, HttpServletRequest request) { if (file.isEmpty()) { return Result.error(请选择文件); } String originalFilename file.getOriginalFilename(); long maxSize 100 * 1024 * 1024L; // 100MB上限 if (file.getSize() maxSize) { return Result.error(文件大小不能超过100MB); } // 防止上传危险文件类型 String ext FilenameUtils.getExtension(originalFilename); if (!allowedExtSet.contains(ext.toLowerCase())) { return Result.error(不支持的文件类型); } // 按日期分目录存储 String datePath new SimpleDateFormat(yyyy/MM/dd).format(new Date()); String realPath uploadRootPath / datePath; File dir new File(realPath); if (!dir.exists()) { dir.mkdirs(); } // 使用UUID重命名避免文件名冲突 String newName UUID.randomUUID().toString().replace(-, ) . ext; file.transferTo(new File(realPath / newName)); String url /upload/ datePath / newName; return Result.success(url); }文件名用UUID重命名是常规做法防止两个学生上传同名文件相互覆盖。文件类型白名单校验建议放在后端而不是前端前端校验很容易被绕过。我见过某些系统只在前端写accept属性后台上传脚本照样能传恶意文件安全隐患很大。补充一句如果把系统部署到云服务器磁盘空间有限建议接入OSS对象存储服务后端只需返回预签名URL。这个改造不复杂Main逻辑是把文件从服务端转发到OSS服务再存储访问链接。初期本地存储足够了。5.2 Excel导出获奖名单的完整流程指导教师经常需要导出名单用于盖章、存档或汇总上报。后端用Hutool的ExcelWriter工具类两行代码就能操作Sheet。GetMapping(/export) public void exportAwardList(HttpServletResponse response) throws IOException { ListAwardVO awardList awardService.selectAwardList(queryParams); ExcelWriter writer ExcelUtil.getWriter(true, 获奖名单); // 自定义列名 writer.addHeaderAlias(studentName, 学生姓名); writer.addHeaderAlias(competitionName, 竞赛名称); writer.addHeaderAlias(awardLevel, 获奖等级); writer.addHeaderAlias(certificateNo, 证书编号); writer.addHeaderAlias(teacherName, 指导教师); writer.write(awardList, true); response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;charsetutf-8); response.setHeader(Content-Disposition, attachment;filename URLEncoder.encode(获奖名单.xlsx, UTF-8)); writer.flush(response.getOutputStream(), true); writer.close(); }导出这块踩过最典型的坑是中文文件名。直接设置Content-Disposition参数会导致火狐浏览器出现乱码必须使用URLEncoder编码后拼到header里。还有一个细节是前端需要以blob方式接收导出文件不能走普通JSON解析否则会出现文件内容被浏览器当文本打开且下载失败。6. 部署上线实践从本地跑通到服务器落地6.1 环境准备与本地联调全流程很多新手在本地联调阶段就被卡住了最常见的坑是前后端端口跨域问题。SpringBoot后端端口配置在application.yml里这里贴一份环境配置的核心参数示例spring: datasource: url: jdbc:mysql://localhost:3306/competition_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 server: port: 8080前端项目开发环境跨域问题我通常建议在Vue配置里开启代理转发vite.config.jsVite或vue.config.jsVue CLI都可以实现。核心机制是前端请求走相对路径如/apiVite开发服务器收到请求后帮我们把/api前缀的请求转发给后端8080端口从而绕过浏览器同源策略限制。生产环境则可以用Nginx做反向代理同时托管前端静态文件和后端接口转发。6.2 生产环境部署流程手册生产环境我推荐一套简单稳定的方案Nginx Jar包 MySQL。前端项目执行npm run build生成dist静态目录交给Nginx托管后端直接打成Jar包用systemd守护进程方式运行。我这里写一份部署命令速查列表# 构建前端产物 npm run build # 打包后端 mvn clean package -DskipTests # 上传jar包后启动 java -jar competition-system.jar --spring.profiles.activeprod # 设置开机自启以systemd注册服务为例 sudo cp competition-system.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable competition-system sudo systemctl start competition-system生产环境数据库地址和密码请署到独立的prod配置文件中不要直接写死在application.yml。密码用Jasypt加密组件混淆或者至少用环境变量注入方式读取不要明文提交到代码仓库。这一条我在自查清单里反复核对过炸过的项目基本都是在密码管理上偷懒。6.3 上线前的数据备份与安全加固竞赛系统上线前数据库备份策略是底线工作。我习惯部署一个每天凌晨的cron任务通过mysqldump备份全库数据到独立磁盘或备份目录备份文件保留近30天。#!/bin/bash BACKUP_DIR/data/backup/mysql DATE$(date %Y%m%d%H%M) DB_NAMEcompetition_db DB_USERroot DB_PASSWORDyourpassword mkdir -p $BACKUP_DIR mysqldump -u$DB_USER -p$DB_PASSWORD $DB_NAME $BACKUP_DIR/${DB_NAME}_${DATE}.sql find $BACKUP_DIR -mtime 30 -name *.sql -delete如果你使用云服务器建议额外配置云厂商的自动化快照策略每周做一次磁盘快照。这样即使人工误操作删数据也能从快照层面恢复形成双保险。安全加固上MySQL不要用默认端口3306暴露公网反向代理层加上IP白名单限制后台管理入口基本可以抵御大部分扫描攻击。7. 常见问题排查与性能调优实录7.1 后端常见异常问题速查表我把这类项目中最常遇到的问题整理成一张速查表实际排查效率能提升不少错误现象可能原因排查命令/手段前端报跨域浏览器Console红色CORS后端未配置跨域过滤器或配置顺序不对检查WebConfig中CorsRegistry是否正确注册数据库密码错误报Access denied环境变量未生效或密码配置多空格SpringBoot启动日志打印明文检查用户登录成功但跳转后刷新掉登录态前端路由守卫未处理Token持久化查看store初始化逻辑是否每次都读localStorage上传图片后无法访问404Nginx未配置upload路径静态资源映射location /upload { alias 磁盘路径; }导出Excel中文乱码Content-Disposition没有URL编码使用URLEncoder.encode查询慢且大表全扫描未建索引或索引未命中EXPLAIN sql语句看type列7.2 性能优化分页查询索引优化实践随着参赛记录增多分页查询性能会逐渐下降最常见的问题在limit做深分页时偏移量过大导致扫描大量无关数据。比如limit 100000, 20这种情况MySQL会先把前10万条全读出来再丢弃产生大量无谓的磁盘IO。优化方案是将分页条件改造为基于上一页最大主键的游标翻页-- 传统深分页效率低 SELECT * FROM competition_student ORDER BY id DESC LIMIT 100000, 20; -- 游标翻页效率高 SELECT * FROM competition_student WHERE id #{lastId} ORDER BY id DESC LIMIT 20;这类优化改动很小但数据量超过20万条时性能差异非常明显。另外一个前端注意事项是表格不要一次性加载全部数据永远要求用户设置分页大小并传pageNum/pageSize参数这既是性能手段也是接口设计规范。7.3 前端内存泄漏与白屏问题排查还有一个我反复遇见的坑Element UI的Dialog或el-table在循环渲染且数据频繁更新时如果ECharts实例没有正确销毁会逐步占满浏览器内存导致白屏卡顿。排查方向是用Chrome DevTools的Profiler记录堆内存变化调用GC后观察Detached节点是否残留。操作建议是动态弹窗关闭时在destroyed钩子里clear组件实例ECharts在beforeDestroy中dispose全局Window事件监听器在destroyed时removeEventListener。这些都属于“看不见但会杀人的细节”上线前最好用性能工具跑一遍。排查白屏问题的优先级建议先看Network请求状态码和返回内容再检查Console报错和JavaScript执行时序最后排查数据渲染异常或组件重复渲染引起的Effect错误从服务接口到前端渲染逐层排查。8. 系统扩展方向与我的实操心得8.1 功能扩展与多端适配方向初版系统正常运行后如果你的实际使用场景更复杂可以沿着几个方向扩展。其一是接入消息通知模块把站内信、邮件、短信通知做成统一的消息中心报名审核通过、赛事开启提醒等事件都能自动推送。其二是增加赛事流程管理的自定义表单配置允许管理员拖拽定义报名表格字段——这个方向工作量大但通用性很强。其三是增加证书在线生成与下载功能通过模板渲染生成电子证书省去手工盖章扫描的流程。如果从技术架构角度看你可以把整个系统按模块拆分出独立的微服务认证服务、竞赛服务、文件服务也可以引入工作流引擎来处理复杂的多级评审流程。但对高校内部管理系统来说单体架构在绝大多数情况下已经足够盲目上微服务反而增加运维负担不建议初期就大动干戈。8.2 从需求理解到落地的几点个人经验做这类管理系统这么多年我最深的体会是技术选型永远是简单场景的第一表达不要为炫技引入复杂框架。报名审核并发不高的业务引入消息队列中间件只会拖垮交付节奏团队成员只会写SQL的时候硬推到NoSQL数据库完全是灾难。第二个体会是在动手编码之前一定要把数据库的表结构和状态机梳理清楚这一点花掉的时间永远是最值得的投资。我见过太多项目因为上线前改字段、改状态导致联调延期的情况而这些问题的根子几乎都出在数据模型设计初期没想清楚。第三点是项目交付后务必写一份简要部署文档和数据库初始化脚本交给接手人时价值比想象中大得多。很多项目换人维护后一脸懵通常就是因为技术文档缺失只能靠读源码摸索。9. 项目源码结构导览与二次开发建议9.1 后端与前端的关键代码位置指引对于想拿这套结构做二次开发的开发者知道关键代码藏在哪个包里是最有价值的。后端包结构建议如下分布com.example.competition/ ├── config/ # 跨域配置、MyBatis配置、文件上传配置 ├── controller/ # REST接口层 │ ├── AuthController.java │ ├── CompetitionController.java │ ├── StudentApplyController.java │ └── ReviewController.java ├── service/ # 业务逻辑层 │ ├── impl/ │ └── service接口 ├── mapper/ # MyBatis Mapper接口 ├── entity/ # 数据库实体 ├── vo/ # 视图对象 ├── common/ # 统一返回Result、异常处理、常量枚举 └── utils/ # JwtUtil、ExcelUtil等工具类这里common包里Result类是所有接口的统一返回模板格式为code、message、data三个字段。前端axios拦截器中对非200 code统一处理这个规范要跟后端同事约定清楚不然每个人写一套返回格式联调时互相折磨。9.2 二次开发的建议顺序如果你想不改变现有主流程只新增模块建议先从数据库建表开始然后写实体、Mapper接口和XML、Service、Controller最后写前端页面和接口封装。这个顺序是瀑布式的每一层依赖前一层按此推进基本不会发生返工。如果要调整审核流程比如增加二级审核最稳妥的方式是给报名表增加一个audit_level字段然后复用同一个审核接口传入当前审核级别。不建议新开一张审核历史表出来因为这会牵扯到前端大量联动改动复杂度成倍增长。9.3 最后分享一个小技巧开发联调时如果发现某些模糊查询带条件后查询结果异常第一步先检查MyBatis XML中 标签的test语句中对象属性名拼写这个错误往往不会在SQL日志直接暴露行号而是会变成不合适的过滤条件返回空数据。日志级别至少要在开发环境把mapper包的日志设置为DEBUG这样能直接打印完整SQL和参数。这个动作能解决联调阶段80%以上的“我怎么查不到数据”类疑问。实际操作中我还会在本地准备一个可以随时重置的测试数据库每次改动表结构后自动执行SQL迁移脚本保持表结构文档和实际库同步——这套协作习惯让我和同事在长期迭代中省去了大量同步沟通成本也算是在这个项目之外沉淀下来的一个额外心得吧。如果你正打算做类似的管理系统尤其是在校生做毕业设计或者课程项目这套SpringBootVueMySQLMyBatis的架构足够撑起一个完整可靠、能演示、能部署的中型管理系统。按我上面梳理的模块顺序逐步实现从数据建模到前端页面从本地联调到上线部署是一条已经被大量项目验证过的稳妥路线。