做毕设选题目的时候奖学金评定管理系统这东西看着不起眼真做起来门道不少。它不像电商秒杀那样有高并发噱头也不像推荐系统那样能晒算法但胜在业务流程完整——学生申请、辅导员初审、评审打分、结果公示、数据导出一整套走下来Spring Boot该练的技术点基本都能碰到。我这两年指导过不少学生用这个题目有人做得顺顺利利答辩过关也有人卡在文件上传、并发提交这类细节上反复折腾个把星期。这篇就把这个系统的完整思路、核心实现、踩坑记录全摊开讲适合正在选毕设题目、或者已经动手写Spring Boot项目的读者参考。1. 项目定位奖学金评定到底在解决什么痛点1.1 高校奖学金评定的真实场景先看业务本身。某高校每年评奖学金流程大概是这样的学院发通知学生在规定时间内提交申请表和证明材料辅导员初审材料是否齐全评审委员会根据绩点、德育分、竞赛加分等维度打分排名最后学院公示名单。听起来不复杂但实际执行起来问题很多。纸质申请表来回交、材料格式五花八门、Excel表格统计经常出错、学生不知道自己材料有没有被收到、评审进度更是一头雾水。更麻烦的是加分规则年年调整同一个奖项去年用一套标准今年又改了手工核对特别容易漏。一个三百人的年级光材料清点就能让辅导员加两天班。这个系统做的事情就是把上面这条链路线上化。学生在线填申请、传材料辅导员后台审核评审委员会按配置好的规则打分管理员发布公示结果。每个环节留痕谁在什么时间做了什么操作都有记录出问题随时可以回溯。1.2 系统角色的业务边界角色设计是这块业务的核心不能上来就怼着一张表做权限。我常用的划分方式是这样的角色核心权限业务动作学生申请、查询维护个人信息、提交申请、上传材料、查看审核进度与结果辅导员初审核对材料完整性、驳回或通过、查看本班申请列表评审委员终审打分按评分项打分、填写评审意见、批量审核系统管理员配置与管理设置奖学金类型、配置评分规则、发布公示、导出名单、用户管理业务上有个容易忽略的点奖学金类型不是一个写死的字典而是需要能动态配置的。因为每学期的奖学金项目可能不同比如校级一等奖学金、励志奖学金、企业奖学金各自的名额、金额、申请条件和材料要求都不一样。如果把这些硬编码在代码里下一学期规则一变就要改代码重新部署非常被动。所以设计时要单独建一张奖学金配置表申请流程和评分规则都跟着配置走。1.3 为什么这个题目适合做毕业设计选题这件事大部分人的纠结是太简单显得水太复杂又做不完。奖学金评定系统刚好卡在中间偏上的位置难度可控但覆盖面广。常见的课程设计只做单表增删改查毕业设计则要求系统化思维这个题目天然就有多角色协作、多步骤流程、状态流转、文件存储、权限控制这些点每一块都能单独拿出来写进论文的系统设计与实现章节。再加上奖学金评定涉及量化打分还能顺带把数据统计和可视化做进去比如按专业统计获奖比例、按奖项类型分析申请人数趋势这些都是答辩时的加分项。和纯商城类题目相比奖学金系统的业务边界清晰不需要模拟支付、不需要处理库存复杂度集中在流程控制上更适合本科生在有限周期内交付一个完整可演示的工程。2. 技术选型与架构设计为什么是Spring Boot这套组合2.1 后端框架选型后端用Spring Boot几乎是这个题目的默认答案原因不复杂生态成熟、资料多、招人认。对毕设来说Spring Boot的自动配置特性省掉了一大堆XML配置让新手能把精力放在业务逻辑而不是环境搭建上。但有几个具体选型值得展开说说。持久层我建议用MyBatis-Plus而不是原生MyBatis。原生MyBatis写简单CRUD要手写XML效率低没意义MyBatis-Plus内置了单表操作、分页插件、自动填充、逻辑删除基本覆盖这个系统的日常需求遇到复杂查询比如多表联查、动态条件筛选时再自己写XML就行。使用率最高的三个特性是分页查询、条件构造器和自动填充。数据库用MySQL5.7或者8.0都行注意8.0的驱动类名和时区配置跟5.7有差异后面踩坑部分会细说。如果想让项目更有看点可以引入Redis做验证码缓存和轮询公告缓存但这个属于锦上添花不是核心。2.2 前端方案的取舍前端是这个题目最纠结的地方很多人在这里反复横跳我得说清楚各自的代价。方案一是前后端分离Vue2加Element UI做后台管理端学生端也用Vue写。优点是界面好看、组件现成、答辩演示很加分缺点是工作量大如果之前没接触过Vue光环境搭建和跨域调试就能耗掉两周。方案二是服务端渲染用Thymeleaf加Bootstrap。优点是项目结构简单不用处理跨域表单提交服务端处理再返回页面非常适合只熟悉Java、前端水平一般的同学。缺点是页面交互弱一些但说实话奖学金系统这种表单密集型应用Bootstrap已经够用了。方案三是用现成的后台管理框架生成前端比如若依这类脚手架直接改业务页面。这个省时间但有个风险生成器代码量大框架自身的表结构和使用约束你得先读懂如果改动时破坏了框架约定排查起来很痛苦。我个人的建议是如果时间充裕且想冲高分选前后端分离如果主要目标是稳妥交付选Thymeleaf方案除非你之前已经用过若依否则别在毕设季临时换框架学一套新东西。2.3 数据库表结构设计数据库设计决定这个项目能写到什么深度。奖学金评定系统核心表我列一下照着这个扩展基本不会跑偏。user用户表统一存学生、辅导员、评委、管理员用role字段区分。单独建学生信息表会带来JOIN和用户同步的麻烦统一用户表再加profile字段更省事。scholarship奖学金配置表名称、类型、名额、金额、申请开始/结束时间、材料要求说明。application申请记录表学生ID、奖学金ID、当前状态、提交时间、最后更新时间。material材料表申请ID、材料名称、文件路径、上传时间。score_detail评分明细表申请ID、评分项ID、得分、评委ID、评分时间。一个申请对应多条评分明细用一条总分数做冗余字段方便排序。review_record审核记录表申请ID、操作人ID、动作通过/驳回/退回、意见、时间。announcement公示表标题、内容、关联的奖学金ID、发布时间。rule_config评分规则表评分项名称、满分、权重、是否启用。这个表结构有两点值得注意。第一application表里一定不要只存最终结果要留状态字段并配合review_record记录流转历史答辩时评审会问怎么保证流程可追溯这就是答案。第二score_detail和application是一对多关系每个评委打分都是一行最后统计总分时用SQL聚合不要在多个评委同时打分时各自更新application表的总分字段否则容易出现并发覆盖问题。2.4 项目分层与目录规范Spring Boot项目分层这件事网上有各种说法但奖学金系统这种规模的工程别搞太复杂。我的建议是controller-service-mapper三层加一个config包放配置类一个common包放统一返回结果、异常处理和工具类一个entity包放数据库实体一个dto包放接收前端参数的类。这里有个新人常犯的错直接把数据库实体类拿去接收前端参数。奖学金的申请表单里有获奖日期证明材料文件名这些字段数据库表里根本不存在如果你直接把前端数据烘进实体类要么报字段不存在要么前端字段和表字段互相污染。正确做法是单独建一个ApplicationDTO校验逻辑写在这层再用Service把DTO转成实体。这个细节写进论文里能体现你有工程意识。3. 核心业务模块实现从申请到公示的完整链路3.1 用户认证与权限控制登录认证是每个系统都绕不开的模块。毕设项目如果还在用session也不是不能跑但我还是推荐用JWT做token认证理由有三点前后端分离场景下JWT天然支持状态无需要后端额外存答辩时能讲清楚无状态认证的原理比session跨域有问题更有说服力后续想扩展APP或小程序端认证逻辑基本不用改。实现上登录接口校验用户名密码成功后用JWT工具类生成token把用户ID和角色写进claim。然后写一个拦截器继承HandlerInterceptor在preHandle里从请求头取token、解析校验、把用户信息放进ThreadLocal。权限控制不用上Spring Security那一套重型方案用一个自定义注解加角色判断就够了。比如给辅导员批量审核接口加上RequireRole(COUNSELOR)注解拦截器里判断当前用户角色是否匹配不匹配直接返回403。这种方式代码量小而且论文里说基于拦截器自定义注解实现细粒度权限控制听上去就很扎实。密码存储一定用哈希不要明文入库。BCrypt是Spring Security自带的好东西就算不用Security全家桶单独引spring-security-crypto依赖也能用BCryptPasswordEncoder做加密校验。3.2 学生在线申请流程学生端申请这个模块流程设计比代码本身重要。核心状态机要提前定义好我一般设这几个状态草稿学生填写未提交可以随时修改。待审核已提交等待辅导员初审。初审通过辅导员确认材料齐全进入评审打分阶段。初审驳回材料不齐或不符合条件退回给学生学生可以补充后重新提交。评审完成评委打完分保存总分和排名。已通过/未通过最终结果。已公示结果已被管理员发布。状态流转的核心原则是每一步只能从前一个合法状态过来不能跳状态。比如待审核状态下不能直接改成已通过必须经过评审完成。代码层面的关键点在事务控制。学生提交申请时要同时插入application记录和material记录如果材料插入失败申请主记录就永远是一条孤儿数据。所以提交接口的Service方法要加上Transactional(rollbackFor Exception.class)并且注意事务只对RuntimeException和rollbackFor指定的异常回滚如果你在事务方法里把业务异常用try-catch吞掉了事务照样不会回滚这个坑我见过不止一次。3.3 量化评分与规则配置评审打分是系统最有业务价值的部分也是论文里最能写深度的模块之一。奖学金评审通常不是一人拍板而是多个评委按维度打分最后取平均分或总分。评分规则的思路是在rule_config表里配好评分项比如学业成绩占比40%学科竞赛加分30%社会实践20%德育表现10%。每个奖项可以关联一套规则存储时用JSON格式存评分项数组也可以拆成rule_config和rule_item两张表。对毕设来说一张表存奖项ID和JSON配置就够了JSON用fastjson或Jackson解析都行但要处理异常格式防御式编程在这里很加分。打分界面做成了表单评委进入待评审列表点开某个申请后各项评分框依次填写分数前端会做范围校验但后端校验绝不能省因为接口可以被直接调用绕过前端。校验逻辑包括每个评分项必须在0到满分之间、总分是否超限、当前申请状态是否允许打分。打分提交时ScoreDetail按评委加评分项粒度为一条记录防止同一个评委重复打分——数据库层面给application_id、judge_id、item_id加唯一索引要比代码里先查后插可靠得多。3.4 多级审核与流程留痕审核流程是这套系统的骨架也是容易被写成一坨屎的地方。很多新手把所有审核逻辑堆在同一个Service方法里用大量if-else判断当前角色和动作结果是代码越来越长自己都看不懂。我建议对审核动作建模。定义一个ReviewAction枚举包括APPROVE通过、REJECT驳回、SUBMIT提交、PUBLISH发布等。审核接口接收的参数就是申请ID加上一个动作IDService里用一个策略表或switch分发到对应的处理方法。每个动作执行时校验前置状态更新状态字段插入一条审核记录这样一个方法的职责就非常清晰测试也好写。这里有一个从实际场景里来的经验辅导员初审通过之后如果评审委员把某个申请驳回了是直接结束流程还是退回辅导员阶段不同学校规则不一样所以代码里不要把流程写死建议在scholarship_config里加一个audit_mode字段用SIMPLE表示直接终审用MULTI表示二级审核。这个设计在答辩时可以主动讲会显得你对业务流程理解很深入。3.5 结果公示与数据导出公示模块由一个公告发布接口加一个公示列表页面组成。管理员选择已经评审完成的奖学金一键发布公示公示内容从该奖学金的晋级名单中生成。公示列表对学生可见同时显示公示起止时间公示期内学生可以反馈异议这个反馈功能用一个feedback表存投诉内容、关联的申请ID和反馈人管理员能看到并处理。数据导出是个容易被低估的模块。很多学生做一个系统界面操作挺顺一提到导出Excel就卡住了。用Apache POI写导出逻辑并不复杂但要处理几个细节列名要清晰、内容要合法、大数据量的分页导出。更省事的方案是用EasyExcel这个阿里开源的库封装了POI读写Excel的内存占用小很多而且注解式指定列名和顺序代码非常短。答辩时如果评委问能不能导出审批表打印你只要说用了EasyExcel写个导出模板现场跑一遍基本就是送分题。4. 实操过程与关键代码实现4.1 数据库初始化脚本这里给出核心表的精简DDL重点关注状态字段、唯一索引和冗余字段的设计CREATE TABLE application ( id bigint(20) NOT NULL AUTO_INCREMENT, student_id bigint(20) NOT NULL COMMENT 学生用户ID, scholarship_id bigint(20) NOT NULL COMMENT 奖学金配置ID, status varchar(20) NOT NULL DEFAULT DRAFT COMMENT 当前状态, total_score decimal(10,2) DEFAULT NULL COMMENT 评审总分冗余, rank_no int(11) DEFAULT NULL COMMENT 排名, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_student_scholarship (student_id, scholarship_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;给student_id和scholarship_id加唯一索引是为了防止同一个学生对同一个奖学金重复提交申请。这个约束用代码检查也能做但数据库层面的唯一索引才是最后一道防线。并发场景下两个请求同时插入唯一索引会在数据库层直接拦住一个比先查询再插入的代码可靠得多。再看评分明细表CREATE TABLE score_detail ( id bigint(20) NOT NULL AUTO_INCREMENT, application_id bigint(20) NOT NULL, judge_id bigint(20) NOT NULL, item_name varchar(50) NOT NULL, score decimal(10,2) NOT NULL, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_app_judge_item (application_id, judge_id, item_name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;评委对同一个申请的同一评分项只能打一次分这是由唯一索引保证的。如果你只用代码判断是否已经打过高并发时两个请求同时通过查询判断就会插入重复数据。4.2 申请提交接口实现申请提交是典型的事务状态校验场景代码骨架如下Service public class ApplicationServiceImpl implements ApplicationService { Transactional(rollbackFor Exception.class) public Long submit(ApplicationSubmitDTO dto) { // 1. 校验申请时间是否在奖学金配置的范围内 Scholarship scholarship scholarshipMapper.selectById(dto.getScholarshipId()); if (scholarship null || !scholarship.isInApplyPeriod()) { throw new BizException(当前不在申请时间内); } // 2. 校验唯一性数据库唯一索引做兜底 Long count applicationMapper.selectCount(new LambdaQueryWrapperApplication() .eq(Application::getStudentId, dto.getStudentId()) .eq(Application::getScholarshipId, dto.getScholarshipId())); if (count 0) { throw new BizException(请勿重复申请); } // 3. 保存申请主记录 Application application new Application(); BeanUtils.copyProperties(dto, application); application.setStatus(ApplicationStatus.PENDING_REVIEW.getCode()); applicationMapper.insert(application); // 4. 批量保存材料 if (CollectionUtils.isNotEmpty(dto.getMaterials())) { for (MaterialDTO materialDTO : dto.getMaterials()) { Material material new Material(); material.setApplicationId(application.getId()); material.setName(materialDTO.getName()); material.setFilePath(materialDTO.getFilePath()); materialMapper.insert(material); } } return application.getId(); } }这里有个细节DTO里的字段和实体字段不完全一致所以不能用BeanUtils直接复制整个对象需要把表单特殊字段单独处理。比如申请时间不能由前端传要在后端取当前时间状态字段前端传什么都没用一律由后端默认赋值。4.3 文件上传的工程化处理证明材料上传是另一个高频踩坑点。用Spring MVC的MultipartFile接收文件核心是存储路径的处理。开发环境把路径写死在配置里没关系但要注意操作系统差异——Windows路径分隔符是反斜杠Linux是正斜杠用File.separator处理或者统一用斜杠让Java自行适配。文件命名一定要防重。直接用原始文件名会出两个问题不同学生可能传同名文件导致覆盖非法字符可能导致路径穿越风险。安全做法是用UUID加时间戳拼新文件名原始文件名只作为展示用存数据库字段。文件大小限制也别漏掉。一般材料都是图片和PDF建议限制每个文件不超过5MB类型限定jpg、png、pdf。Spring的spring.servlet.multipart.max-file-size默认只有1MB不调整的话传大文件会直接报错而且报错信息不容易第一时间想到是这个配置的问题。4.4 使用MyBatis-Plus做动态条件分页查询后台管理页面列表很多每个列表基本都要按条件筛选加翻页。闲得慌去手写分页SQL是纯浪费时间MyBatis-Plus的分页插件配置好之后直接用LambdaQueryWrapper写条件就行PageApplication page new Page(pageNum, pageSize); LambdaQueryWrapperApplication wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(scholarshipId), Application::getScholarshipId, scholarshipId) .eq(StringUtils.isNotBlank(status), Application::getStatus, status) .like(StringUtils.isNotBlank(keyword), Application::getStudentName, keyword) .orderByDesc(Application::getCreateTime); applicationMapper.selectPage(page, wrapper);这段代码非常典型的体现了Wrapper的威力eq的第一个参数是boolean条件只有当前端传了筛选值时才拼接条件为空就跳过。写完这个管理端所有列表查询的逻辑基本就被统一了不用为每个列表单独写一个if判断分支。分页插件记得在配置类里注册新版MyBatis-Plus用MybatisPlusInterceptor加PaginationInnerInterceptor数据库类型要指定MYSQL这个配置漏了的话page查询不会自动拼LIMIT数据量一大就会把全表数据查出来。5. 常见问题与排查技巧实录5.1 文件上传总报错页面却看不到详细原因这是最高频的问题。表现是接口返回500前端控制台只有Internal Server Error后端日志也经常被吞掉。排查顺序先确认三件事第一spring.servlet.multipart.enabled是否开启默认是true没错但如果你用了自定义的WebMvcConfigurer可能把它覆盖掉了第二multipart.max-file-size是否满足材料大小第三上传目录是否有写入权限。我见过最隐蔽的一种情况是Linux服务器下application.yml里写的s/data/upload忘了创建这个目录Spring创建文件时抛出FileNotFoundException但日志被全局异常处理器的catch逻辑吞了只返回一个空洞的失败提示。解决方案是写一个全局异常处理器把MultipartException、MaxUploadSizeExceededException单独捕获返回明确中文提示。既方便排查也直接提升了用户体验。5.2 学生重复提交申请导致脏数据明明代码里有查重逻辑线上还是出现了同一个学生对同一个奖学金的两条申请。原因通常是前端多次点击提交按钮或者学生开两个页面同时提交。数据库层面如果没有唯一索引兜底代码查重永远有并发窗口。解决方案就是我前面说的在application表上建立(student_id, scholarship_id)唯一索引代码查重和数据库约束双保险。同时前端在提交成功后disable按钮并改成提交中状态双击请求直接拦掉。如果项目里已经有重复数据先写SQL合并清理再补唯一索引顺序不能反索引加不上也会报错。5.3 登录状态莫名其妙失效前后端分离项目里常见这个问题。表现是调试时登录明明成功了token也存进localStorage了但下一秒请求就401。排查步骤打开浏览器开发者工具看请求头的Authorization是不是真的带上了。很多人在前端封装的axios里写了请求拦截器但拦截器代码没生效或者拦截器读本地token的key名和后端解析时不一致。另一个典型问题是JWT过期时间配太短比如把过期时间设成30分钟学生填个申请表单超过30分钟就被踢下线了。对毕设演示场景来说token过期时间建议设到24小时以上避免答辩现场演示时突然过期。还有一个很多人没意识到的问题第一次排查跨域时图省事在Controller上加CrossOrigin之后又写了一个全局CorsFilter两者叠加导致预检请求返回了多个Allow-Origin头浏览器直接拦截。建议统一用一种方式配置CORS不要混用。5.4 日期时间字段在前后端传输中的时区问题Spring Boot默认Jackson序列化LocalDateTime时格式是一长串数组数字前端根本没法显示。更隐蔽的问题是MySQL驱动和服务器时区不一致导致存入数据库的时间比实际时间早8小时或者晚8小时。处理方式很简单application.yml里设置时间格式和时区数据库连接串后面加serverTimezoneAsia/ShanghaiJackson的LocalDateTime序列化格式也显式指定。三个地方统一用Asia/Shanghai就能避免绝大多数时间问题。5.5 逻辑删除导致的数据关联失效很多教程推荐用逻辑删除代替物理删除MyBatis-Plus也提供了TableLogic注解加了之后delete操作自动变成update操作。但新手容易忽略的是加了TableLogic后所有查询都会被自动追加deleted0条件如果你在关联表里用原生SQL或者子查询MyBatis-Plus不会自动帮你加这个条件结果就是逻辑删除的数据还在但列表查不出来或者统计数字对不上。对策是凡是涉及逻辑删除字段的表查询全部走MyBatis-Plus的wrapper不要手写原生SQL确需手写SQL时记得手动加deleted0条件。6. 从启动到答辩把项目做成能交付的毕业设计6.1 代码之外必做的三件事第一件事是把README写好。不要只写一句奖学金管理系统就完事。README里至少包含版本环境清单JDK、Maven、MySQL版本、启动步骤建库、改配置、启动后端、启动前端、默认账号密码、目录结构说明。我见过太多学生答辩前三天跑来问为什么启动不了最后发现是JDK版本和课程作业里用的版本不一致出问题就出在环境说明缺失。第二件事是准备测试数据。系统里一定要有真实可演示的数据不要给评委看空表。设计一组完整的模拟数据三个角色账号、五个学生申请、不同类型的奖学金配置、完整的评分记录和公示记录。演示时必须从学生登录开始走一遍全流程让评审看到状态变化。第三件事是录制演示视频。不要让答辩现场当观众面操作翻车环境问题遇上网络问题都不可控提前录好一段流畅操作的视频是保底方案现场演示时也可以边操作边用视频配合。6.2 论文结构的常规套路论文核心章节一般分四块需求分析、系统设计、系统实现、系统测试。奖学金系统的论文有天然的素材优势需求分析可以画用例图系统设计可以画E-R图和架构图系统实现贴核心代码配流程图系统测试列功能测试用例和结果表格。这里有个容易丢分的地方很多论文的测试章节只写功能正常四个字。正确的做法是列出具体的测试用例例如测试用例TC-01学生提交申请后状态变为待审核辅导员登录可见该申请然后附上预期结果、实际结果、是否通过。这种表格一张纸就能体现出你做了系统性测试比在答辩现场嘴上说我都测过有说服力得多。6.3 可扩展的方向建议如果学有余力想加分可以考虑三个方向。第一个是数据可视化把申请人数、获奖率、各学院获奖占比用图表展示后端聚合数据前端用ECharts渲染这个对就业面试也有直接帮助。第二个是消息通知学生提交后、辅导员审核通过后发邮件或小程序订阅消息通知技术上可以对接简单的消息队列或者直接用线程池做异步发送。第三个是移动端适配做一个简化版的小程序或APP学生端的使用场景本来就是随时随地填材料移动端更贴合真实需求。这几个扩展方向不需要全做挑一个认真做成模块就足够在论文的创新点章节里写一大段了。但有一个前提核心流程必须稳定可靠别在扩展功能上花掉了修复核心Bug的时间。我个人带过这么多学生做这个题目的体会是奖学金系统技术难度不算高真正拉开差距的是工程完成度和对业务细节的理解。状态机是否清晰、异常情况是否考虑周全、材料文件是否真的能下载打开、权限控制是否所有接口都生效这些细节决定了答辩时你是被评委追问搪塞过去还是能在台上从容地解释每一个设计决策。最后分享一个很实在的小技巧把所有接口的测试用例表、数据库E-R图、状态流转图放在一个doc里随身带着答辩前自己过一遍比临时翻代码找思路管用得多。