企业官网建设流程全解析

1. 项目概述与核心技术栈拆解

1.1 系统定位与业务场景还原

学科竞赛管理系统，说直白点就是解决“竞赛报名—赛事发布—评审管理—成绩公示”这一整条链路的信息化管理问题。

我接触过不少高校和培训机构的竞赛组织场景，基本都是这个套路：赛事通知靠群消息、报名信息靠问卷星、作品收集靠邮箱、评审打分靠表格、成绩公示靠截图。听着是不是很熟悉？这套流程最大问题就是数据分散、状态不透明、追溯困难。管理员每天被“老师我报名了为什么名单上没有我”“作品交了没啊”这类问题反复轰炸，精力全耗在重复沟通上了。

SpringBoot+Vue这套组合在高校管理类系统中几乎成了事实标准，核心原因有两个维度：其一是SpringBoot的自动配置和Starter机制让后端服务端开发效率高，MyBatis做SQL映射灵活可控，适合竞赛这种业务规则多变的场景；其二是Vue的前后端分离模式，配合Element UI这类组件库，能在短时间内搭出界面规范的PC端管理平台。

1.2 技术栈选型为什么这么固定

Java+MySQL+MyBatis这套组合在很多开发者眼里可能显得“不够新潮”，但放在学科竞赛管理这个业务场景里，其实是深思熟虑过的选择。

后端方面，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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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认证机制与多角色权限控制

管理系统三家角色（学生、教师、管理员）的权限差异是一个核心设计点。学生只能看到报名入口和成绩查询，教师可以通过审核和评分，管理员则可以操作系统设置和全部用户数据。

我用JWT（JSON 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 id="selectStatisticsByConditions" resultType="java.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 test="competitionType != null and competitionType != ''"> AND c.type = #{competitionType} </if> <if test="startTime != null"> AND cs.apply_time &gt;= #{startTime} </if> <if test="endTime != 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 layout="total, sizes, prev, pager, next, jumper" :total="total" :page-sizes="[10, 20, 50]" :current-page="queryParams.pageNum" :page-size="queryParams.pageSize" @size-change="handleSizeChange" @current-change="handleCurrentChange"> </el-pagination>

4.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 { List<AwardVO> 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;charset=utf-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?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: root123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 server: port: 8080

前端项目开发环境跨域问题，我通常建议在Vue配置里开启代理转发，vite.config.js（Vite）或vue.config.js（Vue CLI）都可以实现。核心机制是前端请求走相对路径如/api，Vite开发服务器收到请求后帮我们把/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.active=prod # 设置开机自启（以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_NAME=competition_db DB_USER=root DB_PASSWORD=yourpassword 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 后端常见异常问题速查表

我把这类项目中最常遇到的问题整理成一张速查表，实际排查效率能提升不少：

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迁移脚本，保持表结构文档和实际库同步——这套协作习惯让我和同事在长期迭代中省去了大量同步沟通成本，也算是在这个项目之外沉淀下来的一个额外心得吧。

如果你正打算做类似的管理系统，尤其是在校生做毕业设计或者课程项目，这套SpringBoot+Vue+MySQL+MyBatis的架构足够撑起一个完整可靠、能演示、能部署的中型管理系统。按我上面梳理的模块顺序逐步实现，从数据建模到前端页面，从本地联调到上线部署，是一条已经被大量项目验证过的稳妥路线。