企业官网建设流程全解析

每年毕业设计季，都有同学拿着 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 还是 8，Spring Boot 3 强制要求 JDK 17，你本地跑通了，答辩现场换个环境可能直接起不来。Spring Boot 2.7 在 JDK 8 和 JDK 11 下都能稳定运行，兼容性最好，而且网上资料量最大，遇到问题时搜索成本低。

MyBatis-Plus 的意义不用多说，它保留了 MyBatis 的灵活度，又内置了分页插件、逻辑删除、字段自动填充。最实用的一点是，基于实体类就可以生成建表 SQL 的参考语句，配合代码生成器，能把大量重复的 CRUD 代码压缩到很少的程度。

2.2 数据库设计：答题系统的核心表怎么拆

这是整个项目里最容易被低估的部分。很多同学喜欢把答案塞在一个 JSON 字段里，或者把试卷信息全放一张表里，刚写的时候觉得很方便，做到答题记录和统计时就开始痛苦。

比较合理的拆分方式是至少这些表：

用户表不要搞得太复杂，把班级表单独建出来意义不大，一个 class_id 字段关联班级名即可。题目表真正需要花心思的是选项和答案的存储设计。我建议单选题用 JSON 数组存 options，答案直接存字符串"A"；多选题 options 同上，答案存"ABD"这种组合；判断题 options 固定为 ["正确","错误"]，答案存"正确"。

答题明细表是整套统计体系的数据基础。错题本、知识点正确率、每题正确率全部靠它聚合，这张表千万别省，也别把答案塞到 JSON 里。答题记录表加一个 version 字段做乐观锁，这个后面会详细讲。

2.3 后端分层：不是写代码的规矩，是保护你的围墙

后端我建议严格按三层结构走：controller 只负责接收参数和返回结果，service 负责业务逻辑和事务边界，mapper 只做数据访问。再加上对象转换层，controller 接收 DTO，service 内部用实体或领域对象，最后返回 VO，避免把数据库实体直接暴露给前端。

举个例子，新增一道多选题的接口，controller 收到的是一个包含题干、选项列表、正确答案、知识点等信息的 DTO；service 层里要做的第一件事是参数校验，第二件事是组装 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, List<AnswerItem> answers) { ExamRecord record = examRecordMapper.selectById(recordId); List<Question> questions = questionMapper.selectBatchIds( answers.stream().map(AnswerItem::getQuestionId).collect(Collectors.toList()) ); Map<Long, Question> questionMap = questions.stream() .collect(Collectors.toMap(Question::getId, q -> q)); BigDecimal totalScore = BigDecimal.ZERO; List<ExamAnswerDetail> 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:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar demo.jar

address 是调试端口，注意这个参数默认只监听本机，如果要从外网连，还需要保证防火墙放通了 5005 端口。我的经验是，调试端口不要和业务端口混在一起，单独开一个端口更安全。

第二个原因是 IDEA 的 Remote JVM Debug 配置的 Host 和 Port 写错了。Host 填服务器的公网 IP，Port 填 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 实际开发的节奏上。如果你正准备做这个题目，建议从数据库设计开始就认真对待，后面所有模块都会顺畅很多；如果中途卡住，优先看日志，把日志级别调低，把异常堆栈看完整，大多数问题都能自己定位。

对于远程调试、讲解、定制这些附加诉求，我个人的建议是：先把一个完整闭环跑通，再谈扩展和优化。功能做得再全，如果演示时在某一步卡壳，评分反而会受影响。稳定跑通的主流程，永远是答辩的底气。