做毕设或课设的时候，很多人拿到Springboot学科竞赛推荐平台这个题目，第一反应往往是"这不就是一个竞赛公告管理系统吗？"——把竞赛信息发布出来，学生看看、报名，完事儿。真动手做下去才会发现，这个题目的灵魂其实藏在"推荐"两个字里：系统要根据学生的专业方向、兴趣标签、历史参赛经历，从一堆竞赛里筛出真正适合每个人的那几场。这篇文章我按自己完整做过的类似项目来复盘一下，包含需求拆解、技术选型、数据库设计、推荐策略实现、调试部署和论文写作的全流程，适合正在做这个题目的同学参考，也适合想用一个完整业务项目练手的初级开发者。
1. 竞赛推荐平台的核心：需求拆解与功能边界
1.1 这个项目最容易踩的认知误区
把"学科竞赛推荐平台"当成"竞赛公告发布系统"，是大多数同学踩的第一个坑。公告系统的核心是信息单向流动——管理员发布，学生查看；而推荐平台的核心是双向互动——系统要对每个用户建立画像，然后基于画像做个性化筛选。这两个逻辑写出来的代码结构完全不一样。
我拆解需求的第一步，永远是先列角色。这个平台至少要包含三类角色：学生、教师（竞赛负责人）、管理员。学生端要能浏览竞赛、查看推荐列表、报名、收藏、查成绩和获奖记录；教师端要能发布竞赛、审核报名、录入比赛结果；管理员端要负责用户管理、分类管理、数据统计。三类角色的诉求差异很大，如果一开始不把它们分开梳理，后面写接口的时候会反复推翻重来。
1.2 功能优先级怎么排才不返工
我建议动手前把功能清单分成三级：必须有、最好有、可以有。
- 必须有：登录注册、竞赛信息管理、报名管理、竞赛结果管理、推荐列表。
- 最好有：学生兴趣标签维护、推荐策略可切换、报名截止提醒、数据看板。
- 可以有：获奖证书上传下载、竞赛日历视图、消息通知。
这个排序直接决定你的开发节奏和论文的章节安排。比如"推荐策略可切换"，实现上只是在后台加一个配置项，让管理员在"标签推荐"和"热度推荐"之间选一种，但写论文时就能多出一小节"推荐策略对比实验"，答辩时也更有内容可讲。
我见过不少同学一上来就想搞协同过滤、向量相似度计算，结果数据量太小、标签体系又没建好，推荐结果完全没法看。后来才明白，对这类教学型项目，先把规则权重引擎做好，让推荐逻辑透明、可解释，效果远比盲目上复杂算法要好得多。
2. 技术选型：为什么锁定Spring Boot + MyBatis-Plus + MySQL这套组合
2.1 技术栈的适配逻辑
Spring Boot在这个项目里的定位不只是"框架"，它决定了整个开发过程是否顺畅。对毕设和课设场景来说，Spring Boot最大的价值在于：内置Tomcat、自动配置完善、生态资料极其丰富，任何一步卡住了都能搜到同款问题的解决方案。搭配MyBatis-Plus之后，单表的增删改查几乎不用手写SQL，开发效率提升是肉眼可见的。MySQL作为关系型数据库，支撑用户、竞赛、报名这类强关系数据完全够用。
我也理解有些同学想在这个项目里秀技术，比如上微服务、加Redis、接Elasticsearch。但学科竞赛推荐平台的数据规模，根本到不了需要分布式架构的地步。选型的原则就一句话：够用、熟悉、答辩时能讲清楚。比如说Redis，如果只是拿来存登录验证码，那说服力很弱；但如果用来缓存推荐结果、减少重复计算，就能讲出一个合理的故事。
2.2 环境版本搭配与常见兼容性坑
我实测下来比较稳的环境搭配是：JDK 1.8（导师没有硬性要求就用8，要求新版本就用17）、Spring Boot 2.7.x、MyBatis-Plus 3.5.x、MySQL 5.7或8.0、Maven 3.6以上。
为什么要强调版本搭配？因为Spring Boot 3.x必须配合JDK 17使用，很多旧教程里的写法在3.x下直接报错。MyBatis-Plus和Spring Boot之间也存在兼容性差异，我遇到过mybatis-plus-boot-starter版本偏低、配合Spring Boot 2.7启动即失败的情况，换成3.5.2之后一切正常。
还有一个被忽略的高频坑：中文编码。Maven的pom.xml里必须设置project.build.sourceEncoding为UTF-8；数据库连接URL必须加上characterEncoding=utf8mb4。否则插入中文就乱码，甚至直接报Incorrect string value错误。这个错误我帮同学排查过很多次，每次都不是代码问题，而是编码配置。
3. 数据库设计：从ER模型到落地SQL的每一步
3.1 核心表的拆分思路
学科竞赛推荐平台的数据模型，核心可以概括成一句话：用户、竞赛、标签三者之间的关联关系。具体落地时，我建议至少拆这些表出来：
sys_user：用户表，用role字段区分学生、教师、管理员。competition：竞赛表，保存竞赛名称、分类、时间、计划人数、状态等信息。category：竞赛分类表。tag：标签表，比如"算法""嵌入式""数学建模"。user_tag：学生兴趣标签关联表。competition_tag：竞赛标签关联表。registration：报名表。competition_result：竞赛结果表。recommendation_log：推荐日志表。
推荐日志表是很多同学容易漏掉的。为什么要单独建它？因为论文里要写推荐效果的验证，就得有真实数据支撑。这张表记录了"给谁推荐了什么竞赛、基于什么策略、用户是否点击或报名"，既是功能完整性的体现，也让推荐算法从黑盒变成了可观测、可统计的系统。
3.2 字段设计里的关键细节
竞赛表的"报名截止时间"和"竞赛开始时间"建议直接用datetime类型，不要用varchar存字符串。原因很简单：datetime可以做数据校验（比如截止时间必须晚于发布时间），可以方便地实现"即将截止"的筛选逻辑，排序也省事。
用户表建议单独存"学院"和"专业"字段，不要只靠标签表去推断专业。因为推荐场景里专业相关性是第一权重，兴趣标签是第二权重，两个维度分开存储，推荐策略写起来才清晰。
用户密码不要明文存储，哪怕只是毕设，也要用BCrypt加密。这一点写进论文的"安全设计"小节，是明确的加分项。
报名表建议加上status字段，取值范围是"待审核/已通过/已拒绝/已取消"。很多毕设把报名做成直接成功，省掉审核环节，功能确实变简单了，但"教师端审核"是整个系统里最能体现业务流程完整度的部分，不建议省。有了审核状态流转，用例图、时序图、状态图都更好画。
4. 推荐引擎的实现：规则权重与冷启动处理
4.1 推荐策略的数学模型
推荐模块是这个平台的灵魂，也最值得在论文里详细写。我采用的策略是综合评分排序，公式非常简单但效果扎实：
Score = 0.5 × 专业匹配度 + 0.3 × 标签匹配度 + 0.2 × 竞赛热度
其中竞赛热度可以用"报名人数 ÷ 计划人数"的百分比来衡量。具体实现步骤是：先查出当前学生的专业字段和兴趣标签集合，再遍历所有报名未截止的竞赛，对每场竞赛取出它的分类和标签，然后分别计算三个分数：
- 专业匹配度：竞赛分类等于学生专业分类，得1分，否则0分。
- 标签匹配度：竞赛标签与用户标签的交集数量 ÷ 竞赛标签总数。
- 竞赛热度分：报名人数占比映射到0到1之间。
三个分加权求和后倒序排列，取前N条记录作为推荐结果。用Java 8的Stream流写起来非常顺手，整个推荐逻辑可以控制在一百行以内，但已经能很清楚地解释"为什么推荐这场的理由"。
如果你时间充裕，可以在后台加一个推荐策略开关，让管理员在"综合推荐"和"仅按热度推荐"之间切换，然后对两种结果做效果对比。论文里写这个实验，比单纯贴一段算法代码要有说服力得多。
4.2 冷启动问题怎么处理
新学生没有兴趣标签、新竞赛没有报名数据，这两种情况在真实场景里非常常见，也是答辩时老师最爱问的。我的处理方式是：
- 当用户标签为空时，系统自动用"专业匹配度"作为唯一权重进行推荐，同时在前端给出引导提示"完善兴趣标签可获取更精准推荐"。
- 当竞赛还没有任何报名数据时，热度分置为0.5的中性值，避免新竞赛因为没人报名而永远排不上推荐位。
这个细节如果在论文的"系统实现"一节里写进去，比那些只笼统写"使用了某某算法"的表述要实在得多。
4.3 推荐理由的可视化展示
我强烈建议在推荐列表里给每个竞赛增加一个"推荐理由"字段，比如"因为你的专业（软件工程）与本次竞赛分类匹配，且你关注的算法设计标签与竞赛要求吻合"。实现上就是在生成推荐结果时，把命中的条件拼接成字符串，存到recommendation_log里。
这个功能在答辩现场特别好用。老师看到的不仅仅是一个推荐列表，而是一个"能说清楚为什么这么推荐"的智能系统，观感完全不同。同时它也能体现你的产品思维——用户需要知道自己为什么被推荐，而不是莫名其妙看到几场竞赛。
5. 从源码到可演示系统：调试部署与踩坑记录
5.1 标准启动步骤与高频报错
拿到一个完整的Spring Boot项目源码后，正常启动顺序是：先创建数据库，导入项目里带的SQL文件；然后修改application.yml中的数据库用户名、密码、URL；最后通过Maven打包运行。听起来简单，但每一步都有高频坑。
最常见的问题就是端口占用。Spring Boot默认8080端口，本地如果已经跑了别的服务，启动会直接报"Port already in use"。解决方法是改server.port，或者用命令行查占用进程再杀掉。另一个高频报错是数据库连接失败，需要确认两件事：MySQL服务确实已启动；application.yml里填的IP、端口、用户名、密码和本地MySQL实际配置完全一致。我见过一些同学本地命令行能连上数据库，项目里却连不上，最后发现是密码带了特殊字符没有正确转义。
5.2 前端联调与跨域问题
这个平台如果做前后端分离（比如Vue配合Spring Boot），跨域问题绕不开。开发环境下最简单的做法是写一个CorsFilter，或者在后端接口上加@CrossOrigin注解，允许本地开发端口访问。部署阶段建议用Nginx做反向代理，把前端请求转发到后端端口，这样实际访问的是同源地址，跨域问题自然消失。
5.3 答辩演示环境的黄金路径
答辩或课设验收是很讲究的，系统稳定性与讲解节奏同样重要。我通常会准备一条"黄金演示路径"，按顺序完整跑一遍：
- 登录，演示三种角色的切换。
- 学生端查看推荐列表，讲解推荐理由。
- 点开一个推荐的竞赛，完成报名。
- 教师端审核报名，录入竞赛成绩。
- 学生端看到成绩与获奖记录。
- 管理员端查看统计看板。
这条路径基本覆盖了所有核心功能，演示时节奏清晰，老师能直观感受到系统的完整度。还有一个经验：提前把MySQL服务和后端jar包都启动好，不要在答辩现场等Maven下载依赖，那种场面相当尴尬，而且暴露准备不足。
6. 论文文档的写作结构与加分技巧
6.1 一万字以上的论文怎么分配章节
标题里注明论文文档在一万字以上，这个篇幅对毕设论文来说是正常范围，但很多同学不知道该怎么填满。我建议章节这样安排：
- 第一章 绪论：选题背景、国内外研究现状、研究内容。
- 第二章 相关技术介绍：Spring Boot、MyBatis-Plus、MySQL、前端技术。
- 第三章 需求分析：功能性需求、非功能性需求、用例图。
- 第四章 系统设计：总体架构、功能模块设计、数据库设计。
- 第五章 系统实现：各模块的功能展示与核心代码说明。
- 第六章 系统测试：测试用例设计、测试结果分析。
- 第七章 总结与展望。
一万字听起来多，分配到每章其实还好。重点要放在第四章和第五章，这两章合计应占全文四成以上。数据库设计章节里，把每张表的字段注释写清楚，再配E-R图；系统实现章节里，每个功能模块先用文字描述，再贴界面截图，然后给出核心代码并配上解释。图、文、码三件套式的写法，最不容易写成流水账。
6.2 避免"凑字数"的典型做法
我审过不少类似项目的论文，"凑字数"的特征非常统一：用三页篇幅讲"近年来国家对创新创业越来越重视"之类的背景。这类内容可以有，但最多不超过半页。真正有说服力的是这些内容：
- 数据库表设计里每个字段都有清晰注释；
- 核心推荐算法先用文字讲清思路，再贴关键代码；
- 测试章节有明确的测试用例表格，包含输入、预期结果、实际结果。
每个关键模块至少产出一张截图配一段文字说明，截图自己在本地跑出来的，别去网上找，因为答辩时老师可能让你现场操作，截图和真实界面不一致会很尴尬。
6.3 论文素材的三个隐藏来源
论文素材其实一直藏在项目里，多数人没有主动去挖。
第一是数据结构本身。sys_user、competition、competition_tag、recommendation_log这些表之间的关联关系，直接可以画出E-R图放到设计章节。
第二是测试过程。哪怕只是最简单的功能测试——输入正确账号密码能登录、错误密码被拦截——只要整理成表格，配上几条核心用例，就是完整的黑盒测试章节。
第三是实现过程中的问题记录。比如我在前面提到的编码乱码、端口占用、版本不匹配，这些真实踩坑经历写进"系统实现过程中的问题解决"小节，比任何编造的内容都有说服力，也体现了独立解决问题的能力。
提示：写论文永远记住一个原则——宁可背景少写一页，不能实测少写一段。论文质量不取决于字数，取决于每个字是否经得起现场验证。
7. 这段时间踩坑最多的地方与个人体会
把整个Springboot学科竞赛推荐平台从头到尾做下来，我最想分享的体会是：这类"技术不炫但业务完整"的项目，恰恰是最能体现工程能力的载体。竞赛推荐这个业务听起来不大，但真做下来，角色划分、标签体系建设、推荐策略、状态流转、数据统计这些环节都会完整经历一遍，对理解一个系统的生命周期非常有帮助。
最后说一个实用小技巧：如果你打算把这个项目放进求职的作品集，可以在"推荐理由"功能的基础上再加一个"推荐反馈"按钮，让学生可以标记"感兴趣"或"不感兴趣"，再把这些反馈数据回流到推荐日志表，做成简单的推荐效果统计。这一个小改造，就能让项目从"毕设作品"变成"有产品思维的工程项目"，面试时讲出来的层次感完全不同。完整源码、数据库脚本和配套论文文档，按项目标题里的方式就可以获取，拿到之后建议先按我说的启动流程跑一遍，再对照这篇文章的结构去做二次开发和论文调整，比直接照着敲效率高得多。
