每年毕业设计季都有同学拿着 Java 项目的需求文档来找我问得最多的一个就是基于 Spring Boot 的学生答题练习在线平台这个题到底怎么做说实话这个选题在 Java Web 方向里属于看着普通但做扎实了很能打的类型。它不只是一个增删改查的管理系统而是天然带着题库管理、在线答题、自动判分、错题本、成绩统计这一条完整业务闭环几乎把 Spring Boot 在实际项目里最常用的能力都覆盖了一遍。这篇内容就是围绕这个毕设项目把从选题、表设计、核心功能实现到远程调试、踩坑排查、答辩演示的完整经验拆开讲清楚。不管你是刚接触 Spring Boot还是已经有基础想把这个题目做出亮点都可以直接照着落地。1. 选题逻辑与项目规划为什么这个题是稳且能出彩的毕设1.1 这个选题踩中了毕设的全部评分点做毕业设计最怕两种情况。一种是题目太简单比如纯员工管理、图书管理做完了也就是 CRUD答辩老师问几句底层原理就答不上来另一种是题目太大比如在线教育平台智能学习系统需求摊得又大又宽做到一半发现数据库都有几十张表收不住。基于 Spring Boot 的学生答题练习在线平台恰好夹在两者中间。从表层看它有标准的用户角色、登录认证、题目管理、答题流程满足系统功能完整这条底线往深看它又有很多值得展开的技术点随机组卷、自动判分的规则设计、考试过程中的防重复提交、成绩数据的统计聚合、错题本的更新策略。任何一个点拆开讲都能变成答辩现场的一段技术故事。这个选题的第二个好处是需求来源非常真实。学校里的课后练习、单元测验培训机构里的章节测评甚至企业内部培训的在线刷题底层逻辑都是同一套出题、答题、判分、分析。所以做出来的系统不会让人觉得为了毕设而毕设演示的时候你甚至可以拿出真实题库来当场跑一遍。第三个好处是覆盖面刚好。如果只做前端展示体现不了后端能力如果只做后台管理系统又显得不完整。这个项目天然是管理端 学生端双端结构正好把后台管理系统的表单、表格、权限和前台答题的交互、状态流转都装进去了。无论是学校要求的 B/S 架构还是老师偏好的前后端分离都能落地。1.2 需求范围怎么划才能既不虚胖又不单薄我建议把范围切成四块对应四轮迭代每轮都能形成独立交付。第一轮做基础底座用户注册登录、角色权限、统一返回结构、全局异常处理、数据库设计。这部分的产出不是一个能演示的功能而是后面所有模块的地基。很多同学一上来就写题目管理结果登录接口都是裸奔的后面加权限要返工这个教训挺常见的。第二轮做题库与试卷题目管理单选、多选、判断三种题型、题目的分页查询和条件筛选、试卷的创建与组卷。组卷至少要支持两种方式手动从题库选题以及按规则随机抽题。到这里教师角色基本可以完成建题库、出卷子的工作闭环。第三轮做答题与判分学生端试卷列表、在线答题倒计时、答案提交、自动判分、成绩展示、错题自动收集。这是整个平台的核心也是答辩时最值得详细讲的部分。第四轮做统计与增强班级成绩统计分析、知识点正确率排行、错题重做、成绩导出。这轮不一定全做完但至少要做出一两个可看的分析页面因为统计分析往往是拉开评分差距的地方。这么一分每个阶段都有可交付的成果不管时间紧不紧都能在某个阶段停下来形成一个说得通的完整系统。比一上来就铺二十张表要稳得多。2. 技术选型和系统架构从需求到 Spring Boot 落地2.1 版本组合怎么选Spring Boot 2.7 MyBatis-Plus MySQL每年都有人纠结版本其实没必要追新。我推荐一套最稳妥的组合也是我实际验证过多次的后端框架Spring Boot 2.7.x持久层MyBatis-Plus 3.5.x数据库MySQL 5.7 或 8.0前端Vue 3 Element Plus或者直接用 Thymeleaf 做服务端渲染看个人基础认证授权Spring Security JWT或者 Sa-Token看你想在权限部分投入多少代码量工具库Hutool、EasyExcel、Lombok为什么不用 Spring Boot 3不是不能用而是要考虑学校环境。有些学校的机房 JDK 还是 8Spring Boot 3 强制要求 JDK 17你本地跑通了答辩现场换个环境可能直接起不来。Spring Boot 2.7 在 JDK 8 和 JDK 11 下都能稳定运行兼容性最好而且网上资料量最大遇到问题时搜索成本低。MyBatis-Plus 的意义不用多说它保留了 MyBatis 的灵活度又内置了分页插件、逻辑删除、字段自动填充。最实用的一点是基于实体类就可以生成建表 SQL 的参考语句配合代码生成器能把大量重复的 CRUD 代码压缩到很少的程度。2.2 数据库设计答题系统的核心表怎么拆这是整个项目里最容易被低估的部分。很多同学喜欢把答案塞在一个 JSON 字段里或者把试卷信息全放一张表里刚写的时候觉得很方便做到答题记录和统计时就开始痛苦。比较合理的拆分方式是至少这些表表名职责说明user用户表登录账号、密码、真实姓名、角色学生/教师/管理员、班级question题目表题型、题干、选项、答案、难度、知识点、创建人exam_paper试卷表名称、总分、时长、状态、创建人、多选题判分规则exam_paper_question试卷题目关联表题目ID、题号、分值exam_record答题记录表学生ID、试卷ID、开始时间、提交时间、得分、状态exam_answer_detail答题明细表记录ID、题目ID、学生答案、是否正确、得分wrong_question_book错题本表学生ID、题目ID、错误次数、掌握状态用户表不要搞得太复杂把班级表单独建出来意义不大一个 class_id 字段关联班级名即可。题目表真正需要花心思的是选项和答案的存储设计。我建议单选题用 JSON 数组存 options答案直接存字符串A多选题 options 同上答案存ABD这种组合判断题 options 固定为 [正确,错误]答案存正确。答题明细表是整套统计体系的数据基础。错题本、知识点正确率、每题正确率全部靠它聚合这张表千万别省也别把答案塞到 JSON 里。答题记录表加一个 version 字段做乐观锁这个后面会详细讲。2.3 后端分层不是写代码的规矩是保护你的围墙后端我建议严格按三层结构走controller 只负责接收参数和返回结果service 负责业务逻辑和事务边界mapper 只做数据访问。再加上对象转换层controller 接收 DTOservice 内部用实体或领域对象最后返回 VO避免把数据库实体直接暴露给前端。举个例子新增一道多选题的接口controller 收到的是一个包含题干、选项列表、正确答案、知识点等信息的 DTOservice 层里要做的第一件事是参数校验第二件事是组装 Question 实体和多选题选项字符串第三件事是开启事务调 mapper 保存controller 拿到结果后返回一个带主键的 VO。这样分了层之后以后想加题目审核或题目标签只需要在 service 层扩展不会动到 controller 和 mapper。这套规范还有一个实际好处排错的时候不用猜。接口出问题从 controller 日志看到入参是否正常从 service 日志看到业务走到哪一步从 mapper 日志看到 SQL 执行情况。如果全部业务逻辑都堆在 controller 里事务边界和日志位置都会特别乱排查一次问题够你头疼半天的。3. 核心功能模块拆解题库、答题、判分、错题闭环3.1 题库管理一张表里如何同时装下三种题型题目管理是整个系统的输入源头数据质量决定了后面所有环节的体验。我的建议是题目表里不要为了高级而做复杂设计就用几个关键字段解决问题question_type 存题型content 存题干answer 存正确答案options 存选项 JSON。前端拿到题目后根据 question_type 决定渲染单选组件、多选组件还是判断组件解析逻辑完全统一。题库列表页要做条件筛选题型、难度、知识点、题干模糊查询。分页用 MyBatis-Plus 的分页插件多条件查询用 LambdaQueryWrapper既安全又简洁。批量导入导出是题库管理里非常加分的功能。用 EasyExcel 定义一个题库模板教师按模板整理 Excel 后批量上传后端逐行校验并给出错误行提示。这个功能实现成本不高但演示效果很好建议一定做。3.2 在线答题倒计时、防切屏和提交策略在线答题模块的挑战不在 CRUD而在状态管理。学生点击开始答题后系统要创建一条答题记录为这次考试设定有效期倒计时还要考虑刷新页面、断网、关闭浏览器后重新进入这些情况。我的做法是开始答题时生成 exam_record状态为进行中同时记录开始时间前端倒计时不是简单地在本地计时而是根据后端返回的开始时间和试卷时长计算剩余时间这样即使刷新页面剩余时间还是准的。防切屏功能属于加分项但不要做得太激进。可以记录学生失焦的次数超过一定次数后在后台标记异常而不是直接交卷因为实际使用中总有一些误触。切屏次数可以复用答题记录表加一个 switch_count 字段就行。提交策略上我建议只做整卷提交不做逐题提交。逐题提交不仅容易造成大量并发写请求还会导致判分逻辑分散在多个接口里出 bug 的概率成倍增加。整卷提交时前端一次性把所有答题卡数据发过来后端在一个事务里完成明细保存和判分逻辑清晰得多。考虑到考试过程中可能断网一个很实用的功能是定时保存草稿。前端每 30 秒把当前已答的答案存到本地 localStorage断网恢复后从本地恢复答题状态再和后端做一次确认。这个功能虽然不在需求文档里但真正用起来会非常加分。3.3 自动判分不是简单的字符串比对判分是整个系统的核心业务也是最容易写出 bug 的地方。单选和判断题逻辑很简单学生答案和标准答案字符串完全一致就算对不一致算错。但多选题不能这么做。常见的多选题判分规则有三种全对才得分、漏选给一半分、选错零分。这个规则必须在创建试卷时定义好而不是写死在代码里。我在 exam_paper 表加了一个字段存规则0 表示全对才得分1 表示漏选得一半分。判分代码里先用题目答案和学生答案做集合比较得出是否完全一致是否有漏选是否有错选三个布尔值再根据规则计算得分。还有一个小细节题目分值不一定都是整数。你创建试卷时可能会给一道题 2.5 分如果所有题目得分都用 float 累加很容易出现 99.99999 这种精度问题。我建议所有涉及分数的字段都用 BigDecimal判分计算时用 BigDecimal 的 add 方法累加最后再 setScale(1) 保留一位小数。这个坑我见过不止一次一定要提前避开。3.4 错题本什么时候写入、什么时候更新错题本不需要单独开发一套复杂逻辑核心就是两个时机。第一个时机是整卷提交判分完成后遍历答错的题插入错题本表如果错题本里已经有这道题就把错误次数加 1同时更新最后错误时间。第二个时机是学生在错题本里重做这道题如果这次做对了可以保留记录但标记已掌握不自动删除因为实际学习中更合理的逻辑是保留一段时间再移除避免误删。错题本表不建议用答题明细表实时查询来代替因为错误次数掌握状态这些字段需要单独维护实时查询虽然能拿到历史答错记录但拿不到重做和掌握状态业务表达会变得很绕。4. 关键功能的技术实现细节认证、判分、统计4.1 登录认证JWT 还是 Session这个问题在毕设里讨论度特别高。如果前端是 Vue 分离开发我推荐用 JWT如果后端用 Thymeleaf 渲染页面那直接用 Session 拦截器就足够了。用 JWT 时需要注意三点。第一JWT 要设置过期时间并且在前端放一个 401 拦截器拿到 401 状态时跳转登录页不要等着页面白屏。第二不要把密码明文放在 JWT payload 里只放用户 ID 和角色这些必要信息。第三登出时要让前端清掉 token否则 token 在过期前依然有效。角色权限这里我建议做一个简单的注解校验自定义一个 RequireRole 注解拦截器里从 token 解析出角色判断是否允许访问。不是说非得用 Spring Security 不可但至少要做这个拦截层。老师问起权限设计的时候你能讲出注解 拦截器 token 解析这套链路比说一句用了 Spring Security 但没怎么配置要有说服力得多。4.2 自动判分的代码结构避免在循环里查库很多同学写判分习惯性在 for 循环里逐题查数据库一道题一个 mapper.selectById二十道题就是二十次查询看起来代码很直观但性能和事务都受影响。正确的做法是批量把试卷的所有题目一次性查出来转成 Map再遍历学生的作答数据在内存里完成比对。简化后的思路是这样的public BigDecimal judge(Long recordId, ListAnswerItem answers) { ExamRecord record examRecordMapper.selectById(recordId); ListQuestion questions questionMapper.selectBatchIds( answers.stream().map(AnswerItem::getQuestionId).collect(Collectors.toList()) ); MapLong, Question questionMap questions.stream() .collect(Collectors.toMap(Question::getId, q - q)); BigDecimal totalScore BigDecimal.ZERO; ListExamAnswerDetail details new ArrayList(); for (AnswerItem answer : answers) { Question question questionMap.get(answer.getQuestionId()); boolean correct judgeSingle(question, answer.getStudentAnswer()); BigDecimal score correct ? question.getScore() : BigDecimal.ZERO; totalScore totalScore.add(score); // 组装 ExamAnswerDetail 对象设置 questionId、studentAnswer、是否答对、得分 } record.setScore(totalScore); record.setStatus(1); examRecordMapper.updateById(record); examAnswerDetailMapper.insertBatchSomeColumn(details); return totalScore; }这段逻辑实际跑下来一次整卷提交只会有两次查询和两次写入无论试卷里是十几道题还是上百道题性能都是可控的。批量插入如果用的是 MyBatis-Plus 的 insertBatchSomeColumn要注意这个方法是需要额外配置注入的如果不想配就自己写一个简单的 foreach insert效果也够用。4.3 防重复提交乐观锁比什么都好用学生在答题页面点提交按钮如果网络有抖动他很可能会再点一下第二次请求如果成功就会出现同一份答卷被提交两次、成绩被覆盖或重复插入明细的问题。防重复提交的标准做法是乐观锁。在 exam_record 表加一个 version 字段提交接口的 update 语句里带上 where id ? and version ?更新时把 version 加一。第二次请求进来时version 已经不匹配更新影响行数为 0直接返回您已提交过此试卷。这个办法比前端加 loading 状态可靠得多因为前端防抖只是减少误触并不能挡住并发请求。乐观锁在 MyBatis-Plus 里配置起来很简单给实体字段加 Version 注解再配置一个 MybatisPlusInterceptor 的 OptimisticLockerInnerInterceptor 即可。注意这个拦截器需要和分页拦截器一起注册别少配了。4.4 统计数据怎么查正确率和知识点聚合统计分析页面是很多同学觉得看着复杂、其实很模式化的模块。核心就两类查询一类是单个学生某次考试的正确率另一类是某个班级某张试卷每题的正确率。第一类可以靠答题明细表直接聚合SELECT question_id, COUNT(*) AS total_count, SUM(CASE WHEN is_correct 1 THEN 1 ELSE 0 END) AS correct_count FROM exam_answer_detail WHERE exam_record_id IN ( SELECT id FROM exam_record WHERE student_id ? AND exam_paper_id ? ) GROUP BY question_id第二类是按知识点聚合正确率逻辑一样只是把 group by 换成 question.knowledge_point。前端图表用 ECharts 的柱状图或者雷达图展示最简方式就是后端返回两个数组前端直接填进 series效果完全够用。需要注意的是统计接口不要每次都全表扫一遍。考试记录多起来之后要给 exam_record 表加上student_id, exam_paper_id联合索引给 exam_answer_detail 表加上exam_record_id索引否则查询会很吃力。5. 真实排错案例从启动失败到并发丢分的完整排查链路5.1 启动即退出你以为的代码问题其实是环境问题这个项目里遇到过最典型的启动问题是 Spring Boot 应用启动后立刻退出控制台只看到一行Process finished with exit code 0。第一次遇到的同学常常以为是自己代码写错了其实绝大多数情况是内嵌 Tomcat 端口被占用启动过程中抛出异常但日志级别配置太低没显示出来。排查路径是先看 application.yml 里的日志配置把 root 日志级别临时调成 DEBUG然后再看启动日志里有没有 Port 8080 was already in use 这类字眼找到了就是端口冲突改 server.port 配置就好。还有一种情况是项目里引入了某个数据源依赖但没配数据库连接启动时连接超时直接退出这种日志里通常会有 HikariPool-1 - Exception during pool initialization。如果你在 IDEA 里跑本地项目建议把控制台的Show only output from this process选项关掉让所有日志都打出来否则一些第三方框架的输出会被折叠隐藏排查路径会绕不少弯。5.2 远程调试连不上不是代码问题是 JVM 参数和防火墙问题说到标题里的远程调试很多同学是在把项目部署到服务器时第一次接触。所谓远程调试是让本地 IDEA 里的断点跑到部署在服务器上的 JVM 里去这对定位线上问题很有用。但第一次操作时大概率连不上常见原因有三个。第一个原因是启动命令里没加 JVM 调试参数。Linux 服务器上启动 jar 时一般这样java -agentlib:jdwptransportdt_socket,servery,suspendn,address5005 -jar demo.jaraddress 是调试端口注意这个参数默认只监听本机如果要从外网连还需要保证防火墙放通了 5005 端口。我的经验是调试端口不要和业务端口混在一起单独开一个端口更安全。第二个原因是 IDEA 的 Remote JVM Debug 配置的 Host 和 Port 写错了。Host 填服务器的公网 IPPort 填 JVM 参数里 address 指定的端口Transport 选 Socket然后模式选 Attach。注意不是 Listen是 Attach。第三个原因最容易被忽略生产环境不要开远程调试。远程调试会显著降低 JVM 性能而且有安全风险调试完一定要把 agentlib 参数从启动命令中去掉再重新部署。别图省事留着出了事再后悔就晚了。5.3 判分偶尔丢题循环内外把集合搞乱是最大元凶这个坑值得展开说。当时一个学生反馈做了二十道题的卷子提交后有时候总分是对的有时候少了两三道题的分。排查链路从接口层开始先看提交接口收到的 JSON 里题目数量是不是 20确认数据没丢再看 service 里批量查出来的题目集合数量是不是 20发现也是 20最后在遍历打分时打日志发现遍历到一半集合的 size 变成了 18。问题出在代码里对题目列表做了 remove 操作。他写了类似这样的逻辑for (Question q : questionList) { if (answerMap.containsKey(q.getId())) { // 处理答案 } else { questionList.remove(q); // 在 foreach 里删除元素 } }在 Java 的 foreach 遍历过程中修改集合会触发 ConcurrentModificationException但有时候因为集合底层实现和异常被吞掉不会直接抛错而是表现为遍历提前终止、部分元素被跳过。这就是偶尔丢分的真相。正确做法是遍历过程不要直接改原集合要么用迭代器的 remove要么把需要删除的题目收集到另一个列表循环结束后统一移除。排查这类问题最有效的工具是单测。把判分逻辑抽成独立方法用一组固定题目和固定答案写单元测试跑三次看结果问题很快就暴露出来了。5.4 MyBatis-Plus 自动填充失效常见顺序疏忽项目里给实体类加了 createTime、updateTime 字段并用 MyBatis-Plus 的自动填充功能但插入时时间字段一直是 null。排查后发现自动填充依赖 MetaObjectHandler 实现类上的 Component 注解以及实体字段上的 TableField(fill FieldFill.INSERT) 注解两者缺一不可。更隐蔽的一点是实体类字段名用了 create_time 对应的 createTime如果手动在 application.yml 里关掉了 map-underscore-to-camel-case或者字段上的 TableField(create_time) 但 fill 属性没写对都会导致填充失效。排查这类问题直接在测试类里写一个 insert 方法然后打印返回的实体看自动填充有没有生效比在 controller 层一步步断点要快得多。6. 从调通到答辩部署、演示、定制扩展的实战经验6.1 打包部署jar 和 Docker 两种路线毕设演示时的部署环境五花八门有的在本地电脑有的在学长的服务器有的在机房统一环境。最稳的路线是打 jar 包。在 IDEA 里右侧 Maven 面板执行 package如果提示测试不通过可以加 -DskipTests 跳过。打包完成后在 target 目录会生成一个 jar 文件放到服务器上执行 java -jar xxx.jar 即可。注意数据库连接配置不要写死成本地 localhost用环境变量或者外部配置文件覆盖这样换环境不用重新打包。如果服务器上装了 Docker可以写一个 Dockerfile基于 openjdk:8-jre-alpine 或 openjdk:11-jre-slim 构建镜像再用 docker run 挂载外部配置目录。这个步骤在答辩时属于加分项但不需要做得很复杂能说清楚镜像里只包含 jar 和运行环境配置和数据卷都挂载在外面就够了。还要准备一份初始化 SQL包含建库、建表和演示账号。演示账号至少要有两个一个教师账号一个学生账号密码最好统一方便答辩现场快速登录。6.2 演示脚本按业务闭环走而不是按功能列表走答辩现场最怕的是把系统当成功能清单挨个点点完老师觉得索然无味。建议按一条完整业务闭环来演示第一步用教师账号登录进入题库管理现场新增一道单选题再编辑一道多选题展示批量导入 Excel 的入口第二步创建一张试卷手动选择几道题设置时长和分值发布第三步切换学生账号进入在线答题做几道题后故意答错一题提交第四步回到教师端查看成绩统计和正确率图表再切到学生端打开错题本看到刚才那道错题已经被收集。这条链路走下来老师能直观看到从出题到答题到统计再到错题回归的完整闭环比单纯展示十个页面有说服力得多。演示之前一定要在演示环境里完整跑通两次并把可能出现的网络等待、接口超时提前处理掉。6.3 扩展定制哪些方向改起来性价比最高如果答辩后还有余力或者老师明确说想让你再扩展某个方向我建议优先从下面三个方向入手。第一个是随机组卷算法。很多毕设的随机组卷就是简单地从题库里随机取几道题这在答辩时很容易被追问。可以升级成按难度比例和知识点覆盖范围抽题比如总分 100 分、单选题 20 分、多选题 30 分、判断题 10 分、其他题型 40 分每种题型再按难易比例随机抽。核心是抽题时不重复并且满足试卷总分约束。第二个是答题过程中的防作弊增强。前面说的切屏记录只是基础版可以加一个离开页面超过 N 秒后自动交卷的策略或者在教师端展示每个学生的切屏次数和异常标记做成一个考试监控页面。第三个是导入导出体系。题库 Excel 导出、成绩表 Excel 导出这两个功能实现起来不难但非常实用。用 EasyExcel 的动态头和 WriteSheet 能很快写完演示时视觉效果也干净。至于要不要接第三方登录、要不要做微信小程序端这些工作量都偏大对毕设来说性价比不高不建议临时加需求。最后说点个人的实操体会。带学生做这个选题这几年我最深的感受是这个项目像一个完整的小型软件工程样本从需求拆分、表设计、接口规划到并发处理和排错每一步都能找到真实的产出。它不追求花哨的技术展示但每一步都踩在 Spring Boot 实际开发的节奏上。如果你正准备做这个题目建议从数据库设计开始就认真对待后面所有模块都会顺畅很多如果中途卡住优先看日志把日志级别调低把异常堆栈看完整大多数问题都能自己定位。对于远程调试、讲解、定制这些附加诉求我个人的建议是先把一个完整闭环跑通再谈扩展和优化。功能做得再全如果演示时在某一步卡壳评分反而会受影响。稳定跑通的主流程永远是答辩的底气。