在Java后端这个圈子里SpringBoot早就成了搭建业务系统的首选。最近我花了不少精力把一套在线智慧考公系统从零到一完整落地技术栈就是Java SpringBoot项目编号7948652。这套系统面向的是公考备考场景核心解决的是传统刷题模式下“题海战术效率低、学习数据不透明、错题归因靠感觉”这几个老大难问题。如果你正准备做类似的在线教育、考试测评类项目或者你是Java学习者想找一个能串起SpringBoot、MyBatis-Plus、Redis、JWT这些主流技术栈的实战案例那这篇内容可以给你一份完整的参考。先说一下这套系统到底做了什么。它不是一个简单的题库网站而是把“学、练、测、评”四个环节串在了一起用户端有每日任务、专项刷题、模拟考试、错题本、学习报告管理端有题库管理、试卷组卷、考生管理、成绩统计。整个项目从前端页面到后端服务再到数据库设计都是我一个人开发完成过程中踩了不少坑也沉淀了一些比较实用的设计思路。我打算从整体设计思路拆起把核心模块的实现细节、关键流程的代码逻辑、以及我实际开发中遇到的典型问题都展开聊聊希望能给准备做同类型项目的朋友一些启发也帮大家少走一些弯路。1. 项目整体设计与功能边界梳理1.1 考公系统的需求核心到底是什么在做这个项目之前我先把“考公”这个场景的需求彻底捋了一遍。公考备考和普通的技能考试有个很大的区别知识点覆盖面极广从行测的言语理解、数量关系、判断推理到申论的材料分析每个模块的考察逻辑都不一样。用户在使用刷题软件的时候并不是简单地“做题、对答案”他们真正需要的是三样东西。第一是“节奏感”。备考周期长用户需要知道自己每天该做什么学了哪些模块哪些地方还薄弱。第二是“反馈感”。做完一套题不能只知道对了多少道还要知道自己的正确率在同类考生里是什么水平哪个知识点拖了后腿。第三是“效率”。公考题目量大很多人是碎片化时间学习系统要能快速进入刷题页面翻页要快交卷要快统计要快。基于这三个痛点我把系统拆成了两大端、六个核心模块。用户端有首页工作台、刷题练习、模拟考试、学习报告管理端有题库管理、用户管理、考试管理、数据看板。每个模块都围绕“让用户清楚知道自己该练什么、练得怎么样”来设计而不是堆砌一堆华而不实的功能。1.2 为什么最终选了SpringBoot这套技术组合技术选型上其实没有太多悬念。Java生态里做Web应用SpringBoot就是当前的主流答案尤其适合这种典型的信息管理系统。它内置了Tomcat简化了配置配合SpringMVC做接口层、MyBatis-Plus做数据持久层整个开发链路非常顺滑。我在这套系统里还引入了Redis主要用来做两件事一是缓存热点题目数据缓解数据库压力二是存储用户的登录态信息实现分布式会话管理。因为后期可能要把系统做成多实例部署所以从一开始就没有用传统的Session而是采用了JWT Redis的方案。这里插一句SpringBoot版本的选择也是很多新手容易纠结的地方。如果你的项目是用于学习和毕设场景SpringBoot 2.7.x搭配JDK 8是比较稳妥的组合网上资料多遇到问题好查如果希望体验新特性、用上JDK 17甚至21那可以上SpringBoot 3.x但要注意3.x使用的是Jakarta命名空间很多老教程里的import语句会报错。我做这套系统用的是SpringBoot 2.7.18稳定优先毕竟业务功能才是项目的重点。1.3 核心功能模块的业务闭环整套系统的核心业务链路是管理员在后台录入题目和创建试卷用户在App端Web前端完成练习或考试系统自动判分并记录到个人成绩单然后根据成绩数据生成学习分析报告。这个闭环里有一个特别关键的设计题库的“标签体系”。我每道题目都可以配置多个标签比如所属模块言语理解、知识点关联词辨析、难度等级1-5星、来源年份2024国考。标签体系是后面所有智能推荐和数据统计的基础。比如用户在做“专项刷题”时系统可以根据他最近一次模拟考试中薄弱的知识点标签自动筛选对应难度的题目推送。再比如学习报告模块我并不是只统计一个正确率而是把每个标签维度的正确率都算出来用雷达图和柱状图展示。用户能直观地看到“判断推理中的图形推理正确率只有45%而定义判断正确率到了80%”这样后续练什么就一目了然了。2. 数据库设计与后端架构方案2.1 核心数据表的结构设计思路数据库设计是这类系统的基础我花了很大精力在表结构的设计上。题库类的系统表结构设计好了后面的统计逻辑就会非常顺畅设计不好等做到学习报告功能的时候各种临时表、冗余字段会让你想哭。我这边核心数据表有这几张用户表user、题目表question、题目标签表question_tag、试卷表exam_paper、试卷题目关联表exam_paper_question、考试记录表exam_record、考试答题明细表exam_record_answer、错题本表wrong_question_book。用户表不用多说基础字段加上角色标识区分管理员和普通用户。题目表是重头戏字段设计上我选择了“单选/多选/判断/简答”四种题型统一存储用question_type字段区分选项内容用JSON字符串存入option_content字段。这种设计初期看起来不够“范式化”但实际用起来非常灵活不需要为每种题型单独建表查询和转换都统一了。CREATE TABLE question ( id bigint(20) NOT NULL AUTO_INCREMENT, type tinyint(4) DEFAULT 1 COMMENT 题目类型1-单选2-多选3-判断4-简答, content text COMMENT 题干内容, option_content json DEFAULT NULL COMMENT 选项内容JSON字符串, answer text COMMENT 参考答案, analysis text COMMENT 答案解析, difficulty tinyint(4) DEFAULT 3 COMMENT 难度等级1-5, module varchar(50) DEFAULT NULL COMMENT 所属模块如言语理解, knowledge_point varchar(100) DEFAULT NULL COMMENT 知识点标签, source varchar(100) DEFAULT NULL COMMENT 题目来源如2024国考, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT题目表;考试答题明细表是考试记录的核心每条记录对应考生在某张试卷上的一道答题情况包括题目ID、用户的作答内容、是否正确等。这张表的数据量会比较大所以我设计了联合索引exam_record_id question_id同时在统计用户各个知识点的正确率时通过这张表关联题目表按标签分组统计即可性能也不会太差。2.2 后端分层架构与接口风格后端架构我采用了经典的三层结构Controller层负责接收参数和返回结果Service层处理业务逻辑Mapper层MyBatis-Plus负责数据库操作。为了让代码结构更清晰我还增加了DTO数据传输对象和VO视图对象的拆分避免前端直接拿实体类做响应防止无关字段泄露以及JSON序列化循环引用的问题。接口风格上我全程用的RESTful风格。比如获取题目列表就是GET /api/question创建试卷就是POST /api/exam-paper提交答案就是POST /api/exam-record/submit。所有接口统一返回相同格式的响应体code、message、data。前端拿到这个结构后做统一拦截处理比如code为401时自动跳转登录页code为500时弹出错误提示。{ code: 200, message: success, data: { examId: 12345, totalScore: 78.5 } }统一响应体的设计在项目初期看起来多写了一些样板代码但到了后期调试问题、前端联调的时候好处非常明显所有接口的错误处理逻辑完全一致排查问题不需要在每个接口里重新看返回结构。2.3 JWT登录态设计与权限控制方案登录这块我采用的是JWTJSON Web Token配合拦截器实现。用户登录成功后后端生成一个token返回给前端前端在后续每次请求的Header中携带这个token。后端拦截器会解析token校验用户身份并把当前用户信息放入ThreadLocal中方便后续业务代码获取当前登录用户。这套方案的优点很明显服务端不存储会话状态天然支持水平扩展配合Redis做token黑名单后也能实现“强制下线”等操作。缺点是对token的保护要求更高因为JWT本身是可以解密的所以绝对不能在token里存放密码等敏感信息。权限控制方面我没有引入Spring Security或者Shiro这种重框架因为这套系统的权限模型比较简单只有管理员和普通用户两种角色。我在拦截器里做了一道校验如果请求的接口路径以/admin/开头则校验当前用户角色是否为管理员不是则直接返回403。这种做法简单直接对于后台管理类项目完全够用而且代码逻辑一目了然。3. 核心功能模块的实现细节拆解3.1 在线答题模块考试流程与状态机设计在线答题是整个系统使用频率最高的模块也是我花心思最多的地方。一个完整的考试流程包括创建考试会话、加载试卷题目、提交单题答案、考试超时处理、交卷评分。这五个环节环环相扣任何一个环节考虑不周都会带来糟糕的用户体验。我在设计考试流程时引入了一个“状态机”的概念。考试会话的状态分为未开始、进行中、已完成、已过期。用户在点击“开始考试”的时候后端会创建一条考试记录exam_record并生成一个考试会话标识同时设置结束时间。前端在这个时间段内可以反复拉取试卷题目、提交答案。这里有一个比较关键的边界情况用户作答过程中一直不交卷超过了规定时间怎么办我的处理方式是在后端提交时增加一道校验如果当前时间晚于考试结束时间强制标记考试状态为“已过期”并自动保存用户已提交过的答案给出提示“考试时间已到系统已为你自动交卷”。同时在刷新试卷题目的时候也会检查考试状态是否为“进行中”如果不是就直接返回试卷已结束前端自动跳转到成绩页。这种状态机的设计让前端逻辑变得非常简单前端不需要自己倒计时完再额外做各种校验所有“超时”的判断都以后端时间为准避免了用户本地时间不准导致的问题。在Web端应用里一切以服务器时间为准是一个非常重要的设计原则尤其是考试、秒杀、抢购这类强时效性的业务。3.2 自动判分与主观题评分的取舍判分逻辑是考试系统里最核心的业务逻辑分为客观题和主观题两种情况。客观题单选、多选、判断的判分非常简单将用户提交的答案和标准答案做字符串匹配即可。多选要处理一个细节如果本题为多选用户提交的选项个数与标准答案不一致即使包含正确答案也不能给分而是按0分处理。这是公考行测多选的评分规则少选、多选、错选都不得分。public boolean judgeObjectiveQuestion(Integer type, String userAnswer, String correctAnswer) { if (userAnswer null || correctAnswer null) { return false; } // 单选、判断直接比较 if (type 1 || type 3) { return userAnswer.trim().equalsIgnoreCase(correctAnswer.trim()); } // 多选先排序再比较避免用户选择顺序不一致 if (type 2) { String[] userArr userAnswer.split(,); String[] correctArr correctAnswer.split(,); Arrays.sort(userArr); Arrays.sort(correctArr); return String.join(,, userArr).equals(String.join(,, correctArr)); } return false; }有同学可能会问多选为什么要排序再比较因为用户很可能选的答案顺序是B,D而标准答案是D,B。如果直接字符串比较明明答对了也会被判错。这个坑我在开发初期就遇到过后来用排序再比较的方式解决了。主观题简要论述、归纳概括的判分我采用的是关键词命中评分。管理员在录入主观题时需要额外设置一个“得分要点”即若干个权重不同的关键词。用户提交答案后系统遍历这些关键词命中某个关键词就加上对应分值最后得出总分。这是一种比较简单实用的自动评分策略适合申论客观化较强的题型比如归纳概括、提出对策题真正的大作文就不适合了。在开发这个功能的时候要注意关键词评分只是辅助手段对于重要的申论模拟题还是需要人工批改入口的。系统在判断完客观题后主观题分数会自动计算但管理员有权在后台修改保证灵活性。3.3 随机组卷算法的策略设计模拟考试模块中最具技术含量的就是组卷算法。市面上多数刷题系统采用的是“随机抽取法”就是库里有500道题随机抽100道组成一套试卷。这种做法实现简单但存在明显的不足难度分布不可控可能抽到一套全是简单题的试卷考生成绩虚高知识覆盖面不可控可能某套卷子里有30道数量关系的题目而判断推理只出了5道。我采用的策略是“分层抽样 模块配比”。以行测模拟卷为例我先定义一套组卷策略言语理解25题、数量关系15题、判断推理30题、资料分析20题、常识判断10题总题量100题。每个模块内部再按难度比例抽取比如判断推理模块中难度1-2星抽10题、3星抽12题、4-5星抽8题。这样组合出来的试卷在题型结构和难度梯度上都更加贴近真实国考卷。组卷策略的配置是放在数据库里的管理员在后台可以调整每个模块的题量和难度比例调整后新生成的试卷会按新策略执行。这个设计让系统不需要改代码就能适应不同考试的需求比如省考的行测卷和国考的行测卷在题量和时间上就有差别我把这些做成策略配置项一劳永逸。3.4 学习报告与薄弱点分析的数据统计实现学习报告模块的数据统计是我认为这个系统区别于普通刷题App的核心亮点。我做了一个“知识点正确率热力分析”的功能以知识点标签为维度统计用户最近30天在这个知识点下的做题总量和正确率然后按正确率区间分为优秀≥80%、良好60%-80%、薄弱60%三档。这个统计的SQL实现思路是先按用户ID和时间范围过滤答题明细表关联题目表获取知识标签字段然后按标签分组聚合计算总数和正确个数。SELECT q.knowledge_point, COUNT(*) AS total_count, SUM(CASE WHEN r.is_correct 1 THEN 1 ELSE 0 END) AS correct_count FROM exam_record_answer r LEFT JOIN question q ON r.question_id q.id WHERE r.user_id #{userId} AND r.create_time #{startTime} AND q.knowledge_point IS NOT NULL GROUP BY q.knowledge_point统计出来之后在用户端的学习报告页面上后端把数据封装成每个知识点的正确率列表前端用ECharts渲染成极坐标雷达图。用户可以很直观地看到自己的优势模块和薄弱模块。这里想提醒一点统计数据可以实时从数据库算但是当数据量达到一定规模比如答题流水超过几十万条实时统计的响应时间就会明显变慢。我的优化方案是引入了定时任务每天凌晨跑批把用户当天的做题统计数据汇总到一张统计表中。用户打开学习报告页时读的是这张预计算好的统计数据表查询速度基本在毫秒级。这种“空间换时间”的思路在报表类功能里非常常见也是实际工作中一定要掌握的性能优化手段。4. 考试防作弊与系统安全加固实践4.1 防作弊机制试题乱序与选项乱序在线考试和线下考试最大的不同在于用户可以在任何时间、任何地点参加考试这也给作弊行为提供了更多可乘之机。最常见的情况是几个用户同时开考答案写在小本子上互相抄。为了应对这种情况我的系统实现了“试题乱序”和“选项乱序”双重机制。所谓试题乱序就是同一张试卷不同用户拿到的题目顺序完全不同。A用户的第一题可能是B用户的第三十题。实现方式是在发起考试时后端根据试卷ID查询全部题目后使用随机算法对题目ID列表进行shuffle然后按乱序后的顺序生成试卷内容再把本套试卷的题目顺序快照保存到考试记录中。这里的难点在于乱序只影响题目的展示顺序不影响最终评分。所以评分时需要按照题目ID找到标准答案进行匹配而不是按照题号顺序匹配。如果按题号匹配答案题目一乱序所有答案就全对不上了。选项乱序的实现思路类似对于选择题的选项将A、B、C、D四个选项的顺序打乱再返回给前端。这里要注意一个细节当选项乱序之后标准答案比如是B不能原样保存而是应该在乱序后重新映射到新的选项字母。比如原题的正确答案是“B. 宏观调控”打乱顺序后变成了“C. 宏观调控”那这道题的标准答案在数据库中就应该更新为C。否则用户选了C系统拿B去比对就会误判为错。4.2 接口防刷与异常请求拦截考试系统面临的另一类安全问题是接口被脚本频繁请求。有的用户会写一个简单的脚本短时间内不断请求题目接口把所有题目答案拉取下来然后提交。针对这个问题我在网关层增加了一道简单的防刷拦截对于同一个token如果在1秒内请求次数超过5次则触发限流返回“请求过于频繁”的提示。这个限流逻辑我直接用Redis的INCR命令来实现思路是每次请求时以用户ID接口路径作为Redis的key调用INCR自增并设置过期时间为1秒。如果自增后的返回值大于5说明该用户在这一秒内请求超过5次判定为异常请求返回错误。这个方案简单高效而且Redis的INCR操作是原子性的不会出现并发问题。除了接口防刷还设计了登录验证码和密码加密存储。密码加密用的是BCrypt算法它和MD5最大的区别在于BCrypt每次加密同一个密码得到的密文都不同因为内部加入了随机盐值这样即使两个用户密码相同数据库里存储的密文也是完全不同的大大提升了安全性。在SpringBoot中集成BCrypt非常简单引入 spring-security-crypto 依赖直接用 BCryptPasswordEncoder.matches() 方法做校验即可不需要引入整个Spring Security框架。4.3 前端按题目维度缓存答案防止误丢在线做题最让用户崩溃的体验是什么答了一多半的题不小心关了页面再进来发现作答记录全丢了。为了杜绝这个问题我在设计时采用了“答案实时草稿保存”的机制。用户在点击下一题按钮时前端会自动把当前题目的作答内容发送到“暂存答案”的接口。后端接收到暂存请求后只做一件事把这道题的答案记录到考试答题明细表里如果该题已经有答案则执行更新操作。这样即使前端页面被关闭已经做过的题都有实时记录重新进入考试时前端会拉取当前用户在这套试卷上的所有已提交答案并回显在相应题目上。这个功能让我在开发“浏览器刷新不丢失答案”的需求时几乎没有额外花费精力。细节体验决定了一个系统是否像“商业级产品”而不是“课设作业”。很多初学开发的朋友在搭建这类系统时往往只关注主流程忽略了这种看起来不起眼、但实际上非常影响使用体验的小功能这是后续在开发中需要格外注意的。5. 常见问题与性能优化踩坑实录5.1 大事务导致的连接池连接耗尽项目开发到中期我遇到了一个非常棘手的问题系统运行一段时间后偶尔会出现接口大面积超时数据库连接池报错。排查日志发现是提交考试答案的接口触发了大事务。当时我在提交答案的Service方法上直接加了 Transactional 注解这个方法里包含了保存答题明细、更新考试记录、重新计算学习进度、更新错题本等多个数据库操作。在一次高并发的模拟考试场景下大批量并发提交答案每个请求都占用一个数据库连接并且长时间不释放最终把连接池的连接全占满了后面的请求全部排队等连接系统就“假死”了。解决思路很简单把事务拆细。保存单题答案只需要一个事务而更新学习进度、更新错题本可以放到另外一个独立事务的方法中甚至通过消息队列异步处理。在我这个系统里由于更新学习进度和错题本并不要求即时性我直接用Spring的 Async 注解把这些操作放到了线程池中异步执行主线程只做答题记录保存和返回结果。这个改动上线后接口的并发处理能力提升了不止一个量级。5.2 Redis缓存穿透问题与空值缓存方案题目详情接口一开始是直接查数据库的后来为了提升性能加入了Redis缓存。但我很快发现了一个新问题当一个不存在的题目ID被频繁请求时每次都会穿透Redis直接打到数据库上。如果有恶意请求循环传入不存在的ID数据库压力会瞬间飙升。这就是经典的“缓存穿透”问题。解决方案是在缓存里也缓存“空值”。具体做法是查询题目时先去Redis查如果没查到再查数据库数据库查到了就缓存题目数据并设置过期时间比如30分钟如果数据库也没查到就把空值写入Redis并设置一个较短的过期时间比如5分钟。这样同一个不存在的ID在5分钟内再被请求就直接命中Redis空值返回不会打到数据库。这个方案虽然简单但非常实用。面试中问Redis缓存穿透如果能把“空值缓存”和“布隆过滤器”都说出来就基本能看出你是真正做过项目的。5.3 前端答题计时不准问题与体验优化最后一个坑是关于计时器的。开发模拟考试模块时刚开始做的是前端下拉一个计时器考试结束时前端自动交卷。后来测试的时候发现用户如果打开了多个标签页前端计时器会被浏览器节流导致计时不准确最后交卷的时候用户抱怨“我明明还有10分钟系统却说超时了”。后面我彻底改了方案倒计时以服务器返回的截止时间为准。前端在做题页定时向后端拉取当前考试状态拿到剩余秒数后刷新本地展示。同时按钮上也加了限制一旦后端返回考试已结束前端主动弹出模态框提示“考试时间到正在自动交卷”并调用交卷接口。其实这个问题的根源是前端计时环境不可控后端时间才是可信的。所以在做任何强时效性的业务时尽量以后端时间为准。这也是一个非常典型的“前端体验坑”如果你也打算做考试类系统这个点值得提前考虑进去。写在最后的一点个人经验这套在线智慧考公系统从设计到落地前前后后大概花了两个多月。我最大的体会是做一个业务系统技术选型反而是一开始就能定下来的事真正拉开差距的是对业务细节的理解和打磨。一个功能看似简单真正做起来才发现里面有各种技术边界情况和体验细节要处理。像单选多选的判分规则、考试超时与自动交卷的边界处理、错题本的幂等插入这些问题在没做到那一步之前你很难预知只有真正写代码、跑测试才能暴露并解决。如果你准备参考这个项目做自己的版本我建议先不要急着写代码花两天时间把表结构设计清楚把核心业务场景画成流程图把所有异常情况列出来然后再动手。数据库设计是这个系统的地基地基打好了后面的所有功能都稳了。最后再分享一个小技巧。开发这类系统的过程中一定要自己多用“用户视角”去走查系统不要只作为开发者去测试接口通不通。尝试模拟一个普通用户去刷题、去交卷、去查看学习报告你会发现自己写出来的系统有多少反人类的设计。把这些问题都修复完你的项目就已经超过市面上很大一部分同类课程项目和毕业设计了。