企业官网建设流程全解析

每年到这个时间点，总有准备做毕业设计的同学跑过来问我：学科竞赛管理系统这类题目到底怎么做才不像玩具？我的回答一向很直接——先把业务动线理清楚，再谈技术。SpringBoot+Vue的高校学科竞赛全流程管理平台这个选题，光看标题感觉不算复杂，无非是赛事发布、报名、作品提交、评审打分这样一个闭环。但真正要做一个能交付、能答辩、能扛住评委连环追问的系统，里面值得抠的细节比想象中多得多。

这个系统解决的是什么问题？说句实话，很多高校的学科竞赛管理还停留在表格收集、微信群通知、线下交材料的阶段。竞赛信息分散在不同老师手里，学生报名容易重复或漏报，作品文件格式五花八门，评审数据靠Excel来回传，最终成绩统计更是费时费力。一个能覆盖赛事发布、报名管理、作品提交、评审打分、成绩公示、数据统计的在线平台，正好切中这个真实痛点，这也是为什么这类选题在毕业设计里常年是“经典款”。

这篇内容适合谁看？准备拿这个题目做毕业设计的同学，想了解前后端分离项目完整流程的开发者，以及打算把类似系统扩展成实验室项目、学院服务平台的人。我会从业务拆解讲到数据库设计，再讲后端核心接口、前端页面实现，最后是部署和避坑实录。不灌水，直接讲我在实操中对这类工程的理解和取舍。

1. 项目定位：为什么学科竞赛系统适合做毕业设计

1.1 校园里的真实管理痛点

先说需求来源。高校里的学科竞赛种类很多，有国家级、省级、校级，还有各类行业协会举办的比赛。以前没有系统支撑的时候，学院教务科的老师要手动整理报名表，学生填完Excel发到指定邮箱，老师汇总后还要核对是不是重复报名、是不是缺材料。作品提交阶段更麻烦，不同学生用不同命名方式发文件，有的传网盘，有的发邮件，最后统一收集时要花大量时间去重和整理。

评审环节同样原始。评委老师拿到一堆文档，线下打分后由工作人员手工录入Excel。Excel版本一多，经常出现分数覆盖、丢失记录的情况。学生想查自己有没有获奖，得等公示通知，信息不透明。这些场景叠加起来，就形成了一类需求明确的业务系统：赛事信息集中展示、在线报名、作品统一上传、评审流程数字化、成绩自动汇总公布。

做毕业设计选这类题目有一个天然优势：需求不需要编。所有功能点都来自真实场景，你答辩时能清晰说出“为什么要这个功能”“这个功能解决了什么问题”，这是很多图书管理、商城类选题替代不了的。

1.2 技术栈覆盖面的“性价比”

从技术角度看，这个项目几乎能用上企业级Java后端开发的主流组件：

• SpringBoot负责业务接口和事务管理；
• Spring Security + JWT做登录认证和权限控制；
• MyBatis Plus操作MySQL数据库；
• Vue 3 + Element Plus做前端页面；
• Axios处理前后端交互；
• Swagger生成接口文档；
• Nginx部署构建后的前端静态文件，反向代理后端服务。

对毕业设计来说，这套组合“既有深度，又不至于深到做不完”。你有东西可以在答辩时讲：认证授权怎么设计、数据库索引为什么这样建、事务在哪里使用、跨域问题怎么处理。这些都是面试官和答辩老师爱听的细节。

1.3 全流程拆解：从发布赛事到颁发奖项

整个系统围绕“全流程管理”来设计，我习惯把业务动线拆成六个环节：

1. 赛事发布：管理员创建竞赛信息，设置报名时间、比赛时间、参赛限制。
2. 在线报名：学生组队报名，填写团队成员、指导教师信息，提交后等待审核。
3. 作品提交：报名审核通过后，学生在截止日期前上传作品文件。
4. 评审打分：评委在线查看作品，按多个维度打分，系统自动计算综合分。
5. 成绩公示：根据综合分排名生成获奖名单，学生可在线查询。
6. 数据统计：按赛事、学院、年份等维度统计参赛情况和获奖分布。

抓住这条动线，你的系统功能点就不会散。很多同学做这类项目时喜欢一上来就堆功能，这里加个论坛，那里加个聊天，结果主线业务反而没做扎实。正确的思路是先闭环，再扩展。

2. 技术选型与工程设计：为什么用这套方案

2.1 后端技术栈选择理由

SpringBoot版本我建议用2.7.x，不要盲目追3.x。2.7这个版本足够稳定，和MyBatis Plus、Swagger相关的兼容问题少，网上的资料也最多。等你有精力踩平3.x的坑，答辩早结束了。Java环境用JDK 8或11都行，实测下来SpringBoot 2.7在JDK 8下跑得很舒服。

MyBatis Plus和Spring Data JPA之间，我更倾向于前者。原因很简单：SQL可控。学科竞赛系统的查询场景不复杂，但涉及多表关联、条件筛选、分页排序，MyBatis Plus的LambdaQueryWrapper写起来直观，后期优化SQL也方便。JPA虽然也能做，但对刚接触的同学来说，复杂条件查询的API理解成本略高。

认证方案选择Spring Security + JWT。这里可能有人觉得“我就是个毕设，搞这么复杂干什么，用拦截器不行吗”。我建议咬咬牙上Spring Security，哪怕只是把登录认证、角色权限这部分跑通，也值得。答辩时老师大概率会问“权限控制怎么实现的”，如果你能说出Security的过滤器链、JWT的无状态特性，属于实打实的加分项。

2.2 前端框架选型

前端我用Vue 3 + Vite + Element Plus。Vite的启动速度和热更新比Webpack舒服太多，在开发阶段能省下不少等待时间。Element Plus的表格、表单、弹窗、日期选择器组件直接可用，做一个后台管理系统非常顺手，省去自己写UI组件的时间。

配套用Pinia管理全局状态，Vue Router做路由控制，Axios做HTTP请求封装。为什么不用React？不是React不好，而是这套项目场景下，Vue生态的中文文档和学习曲线更平滑。毕业设计最重要的是在规定时间内做完，而不是追求框架新奇度。

2.3 工程结构与开发环境规划

后端按标准分层结构组织，这是我实测下来最清晰的结构：

• controller：接收请求，做参数校验，调用service
• service：业务逻辑处理，事务管理
• mapper：数据访问层，MyBatis Plus的BaseMapper
• entity：数据库表对应的实体类
• vo：给前端返回的视图对象，避免直接暴露实体
• config：配置类，如Security配置、CORS跨域配置、Swagger配置
• common：统一响应体、异常处理、工具类

前端按模块划分目录，所有API请求集中放一个api文件夹，每个模块一个文件；views下面按角色或业务再分目录。

开发环境建议：后端用Maven构建，前端用npm安装依赖。前后端并行开发时，前端通过Vite的proxy代理到后端端口，避开跨域问题；生产环境再通过Nginx做统一入口。这套联调方式我在实际项目中反复验证过，效率很高。

3. 数据库设计与核心表结构：从报名到奖项的数据闭环

3.1 需求到表结构的推导思路

数据库设计是这类系统最见功底的部分。很多同学上来就建表，想到什么加什么，结果后期发现字段对不上、关系乱成一团。我的习惯是先从业务对象出发，列出系统里有哪些核心对象，再画它们之间的关系。

这个系统里核心对象无非是：用户、竞赛、报名记录、作品、评审记录、奖项、通知公告。

关系是：一个用户可以报名多个竞赛，一个竞赛可以接收多个报名；一条报名记录对应一个团队，团队提交的作品可以有多个版本但最终只有一份有效；一份作品会被多个评委评审，产生多条评审记录；一个竞赛根据评审结果生成多个奖项。把对象和关系理清了，表结构自然就出来了。

3.2 核心表字段设计

下面给出我实际使用过的表结构，可以作为参考模板。

用户表（sys_user）：

竞赛表（competition）：

报名表（signup）：

这里说明一下member_ids字段。用逗号分隔存储成员ID确实不符合严格的数据库范式，第一次评审会可能被老师问到。我这样设计是权衡了毕业设计“够用就好”的原则，如果你想体现更高的设计水平，可以单独建一张team_member表，报名和成员变成一对多关系，这也是我在文中建议的做法。不过如果你的项目演示时间紧张，逗号分隔可以先跑通，答辩时再解释你的取舍思路。

作品表（work）：

为什么要有版本号和is_final字段？因为学生在截止日期前可能会反复修改作品。如果每次提交都覆盖原文件，一旦出现误操作就没有回退能力。加一个版本号，记录历史版本，同时用is_final标记当前生效版本，这个设计在答辩中可以作为亮点讲解。

评审表（review）：

奖项表（award）和通知公告表（notification）相对简单，核心字段分别是竞赛ID、作品ID、奖项等级、证书编号，以及通知标题、内容、置顶状态、发布时间。

3.3 容易忽略的设计细节

建索引一定要有意识地做。报名表里联合唯一索引（competition_id, captain_id）能防止同一个人重复报名同一个比赛，这个在业务上非常实用。竞赛表的status和报名截止时间经常出现在查询条件中，给status加普通索引就够了。作品表的signup_id建议也加索引，方便快速找到某个团队的所有作品。

逻辑删除字段deleted我建议保留。虽然系统里真正删数据的操作不多，但后续一旦有“用户注销”“赛事下架”的需求，逻辑删除能省很多事。配合MyBatis Plus的@TableLogic注解，查询时自动过滤已删除数据，实现成本几乎为零。

我踩过的另一个坑是日期字段的时区问题。配置MySQL连接串时，一定要加上serverTimezone=Asia/Shanghai，否则用SpringBoot默认配置连接，日期时间经常会出现相差8小时的问题，排查起来会让人很崩溃。

4. 后端核心模块实现：登录鉴权与业务闭环

4.1 基于JWT的登录认证流程

登录接口的流程是这样的：前端提交用户名和密码，后端用BCryptPasswordEncoder对比密码是否一致，验证通过后生成一个JWT令牌返回给前端。这个令牌里面包含用户ID、用户名、角色等关键信息，设置一个合理的过期时间，比如24小时。

后续请求前端在HTTP请求头里带上Authorization: Bearer ，后端通过自定义过滤器解析JWT，把用户信息放进SecurityContext中。这样每个接口都能通过工具类获取当前登录用户，不需要每次查询数据库。

有几个关键点提醒一下。生成JWT时密钥要足够复杂，不要用简单的字符串，不然容易被破解。JWT丢失后只能等它过期，所以过期时间别设太长。我在实操中一般设置2小时过期，同时前端在响应401时弹回登录页，这样安全性更好。

Spring Security的配置需要注意白名单放行。登录接口、注册接口、Swagger文档路径、静态资源路径都必须放行，不需要认证就能访问。这里有个容易踩坑的地方：如果Security的过滤链配置顺序不对，Swagger会持续报404，需要在配置类中正确设置antMatchers放行的路径列表。

4.2 赛事发布和报名接口设计

管理员创建竞赛时，表单里包含竞赛名称、主办单位、报名时间段、比赛时间段、团队人数上限等信息。Service层创建成功后，把状态设置为草稿，管理员确认无误后可以点击发布，状态变成报名中。为什么不在创建时直接发布？因为创建过程中可能出现信息填写不完整的情况，草稿机制能避免把残缺的赛事展示给学生。

报名接口是系统里并发压力最大的入口。学生点击报名时，Service层要做三重检查：赛事当前状态是否为报名中、当前时间是否在报名时间段内、该用户是否已经报过名。三重检查缺一不可，而且必须放在同一个事务里。我见过有不少人只做了前两重检查，结果出现了同一个人重复报名的脏数据。第三重检查依赖前面提到的联合唯一索引兜底，双保险更稳。

报名提交后，状态是待审核。管理员在后台看到报名列表，审核通过或拒绝，拒绝时要填写原因，学生端能实时看到。

4.3 作品上传和评审打分逻辑

文件上传使用SpringBoot的MultipartFile接口。上传时要注意：

• 配置spring.servlet.multipart.max-file-size，我一般设为20MB；
• 文件命名使用UUID+原始文件名，避免中文乱码和重名覆盖；
• 按日期目录存储文件，比如/uploads/2025/04/，方便管理；
• 保存文件后，把可访问的URL路径存入数据库work表。

前端提交作品时，后端获取当前登录用户关联的报名记录，确认报名状态是已通过，且当前时间未过比赛结束时间，然后检查是否已有作品记录。如果已有，则说明是更新操作，version加1，新增一条记录而不是修改原记录；然后把之前的版本的is_final标记为0，新版本标记为1。这样既保留了修改记录，又保证评审时读取到的只有最终版。

评审打分时，评委对一份作品按四个维度打分：技术性、创新性、完整性、展示性。每个维度满分100分，后端用加权平均计算综合得分：

综合得分 = 技术性×0.4 + 创新性×0.3 + 完整性×0.2 + 展示性×0.1

如果评委人数少于3人，直接取所有评委得分的平均值；如果评委人数大于等于3人，去掉一个最高分和一个最低分再取平均，这样可以避免单个评委打分偏差过大影响结果。这个计算逻辑我会写进Service层里，在生成奖项前自动算好。

4.4 消息通知机制

系统里有很多需要通知用户的场景：报名审核结果、作品截止提醒、成绩公布通知。最简单可靠的方式是建一张站内信表，用户在系统内查看。同时可以配合JavaMail发送邮件，但邮件发送依赖外部SMTP服务，建议作为附加功能，不要作为唯一通知渠道。

通知的触发点放在业务操作完成之后。比如管理员点击审核通过按钮，Service层保存报名状态后，自动向通知表插入一条针对该学生的新消息。这属于典型的“业务后置通知”，实现成本低且不会影响主流程的响应速度。实测下来，学生反馈最好的功能就是报名审核结果能第一时间看到，再也不用反复问老师“我的报名过了吗”。

5. 前端Vue实现：权限路由与核心页面

5.1 路由守卫与权限控制

前端路由需要区分登录和未登录状态。使用Vue Router的全局前置守卫，在跳转前检查本地有没有token。如果访问的是需要登录才能看的页面但没有token，直接跳转到登录页。

权限控制上，每个路由配置meta字段标明允许访问的角色，比如路由meta: { roles: ['ADMIN'] }，在路由守卫中读取当前用户的角色做比对。菜单栏根据用户角色动态渲染，管理员的菜单能看到“系统管理”“审核管理”，学生只看到“竞赛大厅”“我的报名”“我的作品”。这种“按角色显示菜单”的实现方式最简单，也能达到实际效果。

5.2 竞赛大厅与报名交互设计

竞赛大厅是学生的核心入口，需要做到信息清晰且好用。我的做法是卡片加列表结合，顶部是筛选栏，可以按竞赛级别、分类、状态筛选；每张卡片展示竞赛名称、级别标签、报名时间和状态；点击卡片进入详情页，详情页展示竞赛的完整描述、时间轴和报名按钮。

报名表单要根据竞赛的配置动态变化。如果竞赛设置了需要指导教师，表单就出现指导教师姓名和工号字段；团队赛就出现“添加团队成员”的功能，支持按学号搜索用户。提交前在前端做一次确认弹窗，明确告知“提交后需要管理员审核通过才算报名成功”。

这里有个实操心得：表单校验不能只靠后端，前端也要做一遍。比如手机号格式、学号位数这些，前端先拦截能减少无效请求，提升用户体验。Element Plus内置的表单校验规则配一下就用，成本很低。

5.3 管理后台页面布局

后台管理界面用经典的左侧菜单加右侧内容区布局。左侧按模块折叠组织，管理员端包括数据看板、赛事管理、报名管理、作品管理、评审管理、奖项管理、公告管理、用户管理。

数据看板是答辩时的加分项。我在首页放几个统计卡片：总赛事数、报名人数、作品数、获奖数；下面放两个图表，一个展示近两年各学院参赛人数对比，一个展示不同赛事级别的获奖分布。图表可以用ECharts实现，数据来自后端统计接口，工作量不大但视觉效果很好。

表格页面统一用Element Plus的el-table封装，搭配el-pagination分页组件。这里一个细节需要注意：后端返回的分页数据结构要和前端组件匹配，后端返回data列表、total总数两个字段，前端统一处理，避免每个接口写不同的解析逻辑。

6. 接口联调、Swagger调试与部署上线

6.1 Swagger集成与联调策略

后端接口写完不用Swagger联调，纯靠前端猜参数，效率低得吓人。集成Swagger只需要三步：引入依赖、写配置类、在Controller上写注解。

SpringBoot 2.7配置Swagger有一个隐含的坑：需要设置spring.mvc.pathmatch.matching-strategy=ant_path_matcher，否则启动就会报错。很多同学卡在这一步，把配置加进去就通了。

联调时我通常用Swagger测试三个最关键的接口流程：

• 先调登录接口拿到token；
• 在Swagger界面的全局设置里把token填成Authorization头；
• 再调创建竞赛、报名、作品上传接口，验证整个闭环。

Swagger的好处是接口的参数、响应结构一目了然，前后端并行开发时，后端先行，前端根据Swagger文档写页面，两边不互相等待。

6.2 前后端跨域处理

开发环境下，前端跑在5173端口，后端跑在8080端口，跨域是必然的。两种处理方式我都在用：

第一种，后端开启CORS全局配置，允许指定来源访问。比如：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

第二种，Vite开发服务器的proxy代理。前端请求统一发到/api路径，由Vite代理转发到8080端口。这样浏览器里看请求是同源的，状态更干净。生产环境就交给Nginx做反向代理。

6.3 Maven打包与Nginx部署

后端打包前，检查application.yml中MySQL、文件存储路径等配置是否符合生产环境。执行mvn clean package -DskipTests，在target目录下生成jar包。用java -jar命令启动时，指定配置文件或者直接使用jar包内默认配置即可。

前端执行npm run build，构建产物在dist目录下。部署时用Nginx托管dist文件夹，同时配置反向代理：

server { listen 80; server_name your-domain; location / { root /opt/competition-frontend/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里try_files配置很关键，作用是把所有前端路由都指向index.html，由Vue Router接管路由，否则刷新页面就会404。生产环境部署后，再确认一下后端接口有没有被防火墙拦截，我踩过的坑是Nginx通了，但8080端口没对外开放，导致接口请求全部超时。

7. 常见问题排查与避坑实录

7.1 问题速查表

7.2 我反复踩过的三个坑

第一个坑是Spring Security过滤器链。项目早期，我在放行配置里写了很多路径，但一些动态路径比如/audit/**/approve没有被明确放行，结果接口一进去就被拦截返回401。排查方法是看控制台的过滤器输出日志，每个请求都能看到命中了哪些过滤器，顺着日志找问题特别快。

第二个坑是MyBatis Plus的分页插件没有配置拦截器。直接调用PageHelper或者selectPage会返回全表数据，原因是没有注册PaginationInnerInterceptor。这个插件必须在配置类中注册，否则分页失效，容易让人误以为是自己SQL写错了。

第三个坑是前端打包后路由模式。默认的Vue Router hash模式会在URL里带#号，有些人喜欢改成history模式。但要处理Nginx的try_files配置和404失效问题，不然刷新页面直接白屏。我的建议是：搞不清楚就先用hash模式，毕业设计演示完全够用，不要在这个细节上浪费太多时间。

7.3 答辩时可以主动讲的加分设计

这个系统有几个设计点，在答辩时值得主动展示：

事务设计。报名操作涉及报名记录插入和报名状态更新，用@Transactional保证原子性，任何一个步骤失败都整体回滚，不会产生半截数据。这个细节能体现你对数据一致性的思考。

参数校验。Controller层使用Spring Validation注解，@NotNull、@NotBlank、@Email等，在入口处把非法参数拦掉，避免脏数据流入Service层。这属于工程规范的加分项。

统一异常处理。通过@RestControllerAdvice定义全局异常处理器，业务异常返回400和具体错误码，系统异常返回500，前端根据响应结构统一提示。这个设计能让接口报错不那么“裸奔”，体验好非常多。

如果要讲得再深一些，可以提一下多人协作开发时的Git分支管理策略：主分支保持稳定，功能分支开发完成后合并。答辩老师一般会认可这种工程化思维。

8. 最后再分享一个小技巧

我在实际做这类系统时，有一个习惯是“先做减法，再做加法”。第一版只做到最核心的业务闭环：学生能看赛事、能报名；管理员能审核、能看到报名列表；学生能传作品；评委能打分；成绩能公示。这个闭环跑通了，系统骨架就立住了。剩下的事件通知、数据统计、邮件提醒、图表分析，全部是锦上添花，有空余时间再逐个加。

还有一个容易被忽略的点：演示数据一定提前准备。系统上线后，提前录入几个状态完整的竞赛，每个竞赛都有报名中的、已结束的、已公示的，再准备几个不同角色的测试账号。现场演示时直接登录，鼠标点几下就能展示整个业务流程，而不是现场注册账号、现场创建赛事，这种临场演示的差旅状况太多了。

这类全流程管理系统的核心价值，从来不只是“能用”，而是让用户觉得“好用”。能把这个感知做出来，无论是毕业答辩还是未来的作品集展示，都会是很有说服力的案例。