最近整理项目资料时把这套去年做的Java在线智慧考公系统翻了出来。这是一个基于SpringBoot的完整Web项目覆盖题库管理、在线刷题、模拟考试、自动判分、学习数据统计这些核心模块。当时接这个需求是一位做公考培训的朋友找上门说他们的学员还在用纸质题库刷题老师靠Excel表格统计成绩急需一个能在线模考、自动生成学习报告的系统。项目从需求梳理到部署上线大概用了三周。这篇文章我会完整复盘开发全过程需求怎么拆、技术怎么选、题库和组卷模块怎么做、模拟考试的判分链路怎么设计、部署时踩了哪些坑。不管你是想用SpringBoot做在线教育类项目还是在准备Java后端面试想找一个真正能讲清楚的项目经验这篇都值得看完。1. 接到考公系统这个需求时我先做了三件事1.1 先把智慧两个字翻译成功能点智慧考公听起来很玄实际拆开就是四个核心场景刷题、模考、错题、报告。公务员考试和普通学科考试不一样它分为行测和申论两大类。行测里面又细分为常识判断、言语理解、数量关系、判断推理、资料分析五个模块全是客观选择题申论则是主观题需要人工阅读批改。这意味着系统不能只做简单的题库答卷功能还要处理客观题机器判分、主观题人工批改这种混合判分模型。另外公考备考有极强的刷题属性。学员不会只做一套卷子而是每天零散地做几十道题跨多个知识点。如果系统不记录每次练习的结果那智慧就无从谈起。所以我在需求阶段就定下了原则每一次答题行为都要落库用户对每道题用了多长时间、做没做对、属于哪个知识点全部保存下来。这些数据后面会直接喂给学习报告模块用来分析薄弱点。1.2 划清MVP边界哪些功能第一版必须做和需求方聊完之后我把功能分成三类必须做、可延后、砍掉。第一版必须做的是用户注册登录、题库浏览与刷题、模拟考试含计时、客观题自动判分、主观题人工批改入口、错题本、个人学习报告、后台题库管理。这些功能构成了一个完整的业务闭环学员进来能刷题刷完有反馈错题自动沉淀学习成果可视化。可延后的是课程视频模块、在线支付、社区讨论区。这类功能看着加分但会严重拖慢开发节奏。尤其是视频模块涉及存储、转码、播放权限一堆事不是三周能搞定的。直接砍掉的是APP端。第一版只做Web端手机浏览器访问响应式页面就够用了。等PC端跑通、题库量和用户量起来之后再考虑小程序或者APP。事实也证明这个决定是对的上线后大部分学员都是用手机浏览器打开的响应式布局完全能撑住。1.3 从需求里挖出的技术难点清单我把业务需求翻译成技术问题之后整理出了四个最难啃的点第一智能组卷。模拟考试不能简单地随机抽题要保证试卷的题型分布、知识点覆盖、难度比例都合理。比如行测模考卷常识题、言语题、数量题、判断题、资料分析题的数量要固定难度比例要接近真实考试的基础:中等:困难5:3:2。第二考试计时与防作弊。前端倒计时只能作为展示后端必须单独维护考试开始时间和截止时间否则用户改一下浏览器时间就能无限延长答题。这个校验逻辑必须在交卷接口里做。第三重复提交的并发控制。用户交卷时双击按钮或者前端连续重试会导致同一份答卷被提交多次。轻则数据重复重则判分结果覆盖异常。这个属于典型的并发幂等问题后面会详细讲。第四主观题判分。申论这种题目机器暂时没法给出准确分数需要设计一个待批改的状态让老师在后台人工打分。这个工作流必须融入到考试状态机里不能独立在系统之外。这四个难点决定了技术选型的方向需要Redis扛缓存和分布式锁需要状态机管理考试生命周期需要策略模式处理不同组卷规则。2. 工程落地SpringBoot 3.x JDK 17 MyBatis-Plus 这套组合2.1 版本选型为什么没有停留在SpringBoot 2.7现在打开搜索引擎搜SpringBoot教程大量结果还停留在2.x时代。热词里那个springboot版本太高说的就是3.x带来的兼容问题。但我还是选了SpringBoot 3.2.4 JDK 17这套组合原因很简单新项目不该用已经进入维护尾期的旧版本。下面这张表是我当时整理的对比也分享给大家对比项SpringBoot 2.7.xSpringBoot 3.2.x基础JDKJDK 8/11JDK 17Jakarta命名空间javax.*jakarta.*依赖生态基本全部兼容部分旧依赖需升级换新安全维护期已停止社区维护长期支持性能基准启动更快内存收益明显JDK 17是Java的长期支持版本SpringBoot 3.x完全基于JDK 17构建在虚拟线程、容器化部署方面都有优化。既然是从零开始的系统就没有理由背着历史包袱。当然版本太高的坑确实存在。我在项目里就遇到了三个兼容问题第一个是持久层依赖。MyBatis官方早期提供的mybatis-spring-boot-starter只适配到2.xSpringBoot 3.x必须用mybatis-spring-boot-starter3.0.3以上版本或者直接用MyBatis-Plus 3.5.5。第二个是分页插件。PageHelper早期版本和SpringBoot 3.x不兼容会直接报Bean创建异常需要升级到1.4.7以上。第三个是数据库驱动。MySQL驱动坐标从mysql:mysql-connector-java变成了com.mysql:mysql-connector-j类名也从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver。这些坑在SpringBoot 2.7时代完全不存在。我的建议是如果你在导入依赖时发现某个starter和SpringBoot 3.x不兼容不要硬妥协去Maven仓库搜这个组件的最新版本通常官方已经适配好了。2.2 工程目录与统一响应体项目结构按照业务域划分没有用传统的controller/service/mapper三层包到底com.example.exam ├── common // 统一响应、全局异常、常量 ├── config // Redis、MyBatis-Plus、Web配置 ├── controller // 接口层 ├── service // 业务层 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 入参/出参对象 └── enums // 状态机、题型等枚举统一响应体是必做的一步省得每个接口都写一套返回格式。我定义了一个ResultT泛型类Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }配合RestControllerAdvice做全局异常处理业务代码里只需要抛出自定义异常比如BusinessException(500, 试卷不存在)前端拿到的永远是结构一致的JSON。这个小设计在后期联调时节省了大量时间强烈建议每个项目都这么做。2.3 持久层与权限认证用最少代码搞定持久层选了MyBatis-Plus 3.5.5理由很直白公考系统的核心操作是大量的单表CRUD和分页查询MyBatis-Plus内置的分页插件和LambdaQueryWrapper可以把常规查询的代码量减少一半。比如刷题列表的分页查询只需要这么写PageQuestion page questionMapper.selectPage( new Page(current, size), new LambdaQueryWrapperQuestion() .eq(Question::getSubject, request.getSubject()) .eq(request.getDifficulty() ! null, Question::getDifficulty, request.getDifficulty()) .orderByDesc(Question::getCreateTime) );权限认证这块没有引入重型的Spring Security用了Sa-Token。它最吸引我的是配置极简几行代码就能完成登录、登出、权限校验。考公系统本身角色就两种学员和管理员Sa-Token的StpUtil.checkLogin()和注解SaCheckRole(admin)完全够用。3. 题库与智能组卷整个系统的发动机3.1 题目表结构一张表撑起刷题、模考、错题三个场景题库是整个系统的数据底座表结构设计直接决定了后续功能的复杂度。我的核心设计思想是题目只存一份通过冗余字段支撑不同场景的查询。题目表的核心字段如下CREATE TABLE question ( id bigint NOT NULL AUTO_INCREMENT, subject tinyint NOT NULL COMMENT 模块1-常识 2-言语 3-数量 4-判断 5-资料 6-申论, type tinyint NOT NULL COMMENT 题型1-单选 2-多选 3-判断 4-主观, knowledge_point varchar(64) NOT NULL COMMENT 知识点编码如XCMK-001, difficulty tinyint NOT NULL COMMENT 难度1-简单 2-中等 3-困难, content text NOT NULL COMMENT 题干, options text COMMENT 选项JSON数组格式, answer text COMMENT 参考答案, analysis text COMMENT 解析, create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_subject_difficulty (subject, difficulty), KEY idx_knowledge_point (knowledge_point) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT题目表;选项用JSON数组存储比如[A.社会契约论,B.人民主权论]。这么做虽然多了一次序列化反序列化但换来了极大的灵活性——不同题型的选项数量不一样用关系表存会很别扭。除了题目表还需要两张关联表exam_paper保存试卷基本信息比如试卷名称、类型模考/练习、总时长、总分exam_paper_question保存试卷与题目的关联关系包含题目在试卷中的序号和分值。这里有一个关键点试卷里的题目一旦组好就把题目内容快照到exam_paper_question表里。这样即使后来题库中的题目被修改已生成的试卷也不会受影响学员练习和考试看到的内容是稳定的。答题明细表exam_answer_detail也很重要它需要保存用户提交的答案快照和判分结果不能交卷之后再去question表回溯答案否则后面如果题目更新过历史数据就全乱了。3.2 第一批题库数据从哪来EasyExcel批量导入系统做完了没有题等于空壳子。第一批5000道题的来源是需求方那边积累的Excel题库文件。我写了一个批量导入接口用EasyExcel解析上传的Excel逐行转成Question对象后批量插入数据库。导入校验是这次开发中比较容易忽略的一环。Excel里的数据不像手工录入那么规范多选答案的分隔符可能是中文逗号也可以是英文逗号解析里有的行缺少解析文本还有少量题目选项不完整。针对这些情况我在导入逻辑里加了逐行校验题干、模块、知识点不能为空选择题的选项数量不能少于2个答案必须合法不能出现选项里没提供的字母多选题答案里的选项不能重复校验不通过的行单独记录错误原因不影响其他正常行导入。这个设计在第一次导入时帮了大忙需求方返回来的Excel里有几十行脏数据系统直接把问题定位到了具体行号省去了一封邮件来回传的折腾。3.3 智能组卷策略从随机到按知识点加权组卷模块是题库和模考之间的桥梁。刚开始我图省事准备直接ORDER BY RAND()随机抽题但被需求方一句话否了我要能出针对某个薄弱考点的卷子比如这个学员资料分析弱你就给我多出几道资料分析题。所以组卷逻辑用了策略模式定义了统一的接口public interface PaperGenerateStrategy { ListQuestion generate(PaperGenerateRequest request); }第一版实现了三种策略随机组卷按题型和模块比例随机抽取。比如一份行测模拟卷常识20题、言语40题、数量10题、判断35题、资料20题然后在这五个模块内部分别按难度比例随机抽题。知识点加权组卷先分析用户近30天的错题数据找出正确率最低的5个知识点在抽题时给这些知识点增加权重。实现方式是在按知识点分组后从薄弱知识点中多抽取20%的题目。真题/模拟卷复刻完全固定题型和知识点分布从题库里按已有真题试卷的结构匹配题目。抽题代码的核心逻辑大概是这样Override public ListQuestion generate(PaperGenerateRequest request) { ListQuestion result new ArrayList(); for (PaperGenerateItem item : request.getItems()) { // 每个item包含模块、题型、题量、难度分布比例 ListQuestion pool questionMapper.selectList( new LambdaQueryWrapperQuestion() .eq(Question::getSubject, item.getSubject()) .eq(Question::getType, item.getType()) ); // 按难度分布和题量进行加权随机 result.addAll(pickByDifficulty(pool, item)); } // 种子打乱 Collections.shuffle(result); return result; }这里要注意一次性把所有符合条件的题目都捞出来在数据量大时不一定高效。优化方式是先按难度分组统计数量再通过LIMIT分页随机抽取把内存压力降到最低。3.4 用Redis缓存组卷结果组卷操作本身涉及多次数据库查询特别是知识点加权组卷还要先统计错题数据。如果用户每次进入模考配置页都要等两三秒体验会非常差。我的方案是用户确认试卷配置后后端把生成的题目ID列表缓存到Rediskey的设计是paper:temp:{userId}:{configHash}TTL设置为30分钟。用户进入答题页时优先从缓存拿题缓存过期或不存在再触发实时组卷。缓存只存题目ID和题目在试卷中的序号真正的题目内容在用户开始考试时才批量查出。这样既保证了组卷速度又不会因为缓存占用太大内存。实际测试下来走缓存的试卷加载接口从原来的2000ms降到了200ms以内。4. 模拟考试核心链路状态机、判分引擎与并发控制4.1 考试会话状态机从未开始到已批改模拟考试不是简单地把题目展示给用户它有一个完整的生命周期。我用状态机来管理考试的流转状态含义允许流转到NOT_STARTED已创建试卷未开始答题IN_PROGRESSIN_PROGRESS答题中倒计时生效SUBMITTED, TIMEOUTSUBMITTED已交卷客观题已判GRADEDGRADING有待人工批改的主观题GRADEDGRADED全部判分完成无TIMEOUT超时强制交卷SUBMITTED, GRADING在代码里我用枚举类定义这些状态并禁止在Service层之外手动赋值。所有状态变更必须走统一的方法比如startExam()、submitExam()、gradeAnswer()这样才能在状态变更前后插入业务逻辑比如检查当前用户是否是考试的创建者、判分是否已完成等。这里有一个细节超时交卷不是靠前端定时器触发的。后端的定时任务每隔30秒扫描一次IN_PROGRESS状态的考试记录如果发现当前时间已经超过考试截止时间就自动执行交卷逻辑。这样即使学员中途关闭了浏览器考试也会在超时后自动判分不会被永远卡在答题中。4.2 交卷时发生了什么判分引擎的设计交卷接口是整个系统最核心的交易链路设计上我分成了五个步骤全部放在一个事务里第一步参数校验。检查考试记录是否存在、状态是否为IN_PROGRESS、当前时间是否在有效期内。第二步批量保存答题明细。前端把用户选好的答案一次性传过来后端循环插入到exam_answer_detail表中。这里要注意答案和题目的对应关系防止前端篡改题目编号所以每一条明细都要校验题目确实属于这张试卷。第三步客观题判分。遍历答题明细逐题和question的答案做对比。单选和判断题直接判断是否相等多选题需要把用户答案字符串拆开排序后再对比避免AB和BA被误判为错误。第四步判断是否存在主观题。如果有申论题记录状态标记为GRADING表示等待管理员批改如果没有主观题直接置为SUBMITTED总分数已经完整。第五步生成考试统计。计算这次考试的总分、客观题正确率、各模块正确率写入exam_record表的冗余字段。这样后续查询考试成绩列表时不需要实时聚合直接读取即可。判分核心代码片段如下Transactional(rollbackFor Exception.class) public ExamSubmitResult submit(ExamSubmitRequest request) { ExamRecord record examRecordMapper.selectById(request.getExamRecordId()); if (!Objects.equals(record.getStatus(), ExamStatus.IN_PROGRESS.getCode())) { throw new BusinessException(当前考试状态不允许交卷); } // 保存答题明细 ListExamAnswerDetail details buildDetails(request, record.getId()); examAnswerDetailMapper.batchInsert(details); // 客观题判分 int objectiveScore calculateObjectiveScore(details); boolean hasSubjective details.stream().anyMatch(d - d.getQuestionType() 4); // 更新考试记录 record.setObjectiveScore(objectiveScore); record.setStatus(hasSubjective ? ExamStatus.GRADING.getCode() : ExamStatus.SUBMITTED.getCode()); examRecordMapper.updateById(record); return new ExamSubmitResult(objectiveScore, hasSubjective); }4.3 并发重复提交一个容易被忽视的线上故障我印象最深的一个坑就是交卷接口的并发重复提交。测试阶段怎么点都没问题但上线后有个学员反馈考试交完卷后成绩不对。查看日志发现他的考试记录状态被连续更新了两次第一次交卷正常判分后第二次重复提交把总分覆盖成了一个不完整的数据。原因在于前端在交卷按钮点击后没有立即禁用按钮加上网络有抖动浏览器自动重试了请求。两个请求几乎同时到达后端都通过了状态校验此时记录状态还是IN_PROGRESS然后各自执行了一遍判分逻辑。解决方案是两层防护。第一层是数据库层面exam_record表中增加submitted字段并加唯一约束uk_exam_submitted (id, submitted)这样第二次提交时因为违反唯一约束而失败。这个方案能兜底但报错信息不够友好。第二层是应用层加Redis锁。在交卷逻辑入口处用SETNX命令获取一把分布式锁Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(exam:submit: examRecordId, 1, Duration.ofSeconds(5)); if (!Boolean.TRUE.equals(locked)) { throw new BusinessException(正在处理交卷请勿重复操作); } try { // 这里再做一次状态校验然后执行交卷逻辑 } finally { stringRedisTemplate.delete(exam:submit: examRecordId); }锁获取成功后、执行业务前还要再查一次考试状态。如果此时状态已经变成SUBMITTED说明前面已经有一个请求完成了交卷直接返回上一次的判分结果就好。这就是幂等设计同一个交卷请求不管执行多少次最终结果是一样的。这个问题的本质是先检查后执行的竞态条件。掌握了这个案例Java面试里被问到幂等性设计时你可以讲得比背八股文的人生动得多。5. 智慧从哪来刷题记录、错题本与个人分析报告5.1 全链路答题埋点前面说过的每次答题行为都要落库在这里落地。我专门建了一张practice_record表CREATE TABLE practice_record ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL, question_id bigint NOT NULL, subject tinyint NOT NULL, knowledge_point varchar(64) NOT NULL, is_correct tinyint NOT NULL DEFAULT 0, duration_seconds int NOT NULL DEFAULT 0, practice_source tinyint NOT NULL COMMENT 1-练习模式 2-模拟考试, create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_user_knowledge (user_id, knowledge_point) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT刷题记录表;用户每次答一道题无论练习还是考试都会插入一条记录。我还让前端把从读题到选择答案的耗时传回来记录到duration_seconds字段里。这些数据看起来不起眼但对后面的学习报告来说价值很大。一开始我担心这张表会膨胀得很快但算了一笔账一个高活跃学员一天刷200道题1000个学员一天也就20万条记录MySQL的普通索引完全扛得住所以没有做分表。如果以后用户量翻几十倍这套设计也可以平滑地迁移到分区表。5.2 错题本不是简单查表要解决变式问题错题本是公考学员的刚需但实现方式有讲究。最粗暴的做法是把所有答错的题加到一个wrong_question表里直接查出来展示。但这样会有一个问题学员反复做错同一道题时如果已经通过看解析学会了下次做对了错题还应该出现在错题本里吗我的设计是错题本由答错记录触发由连续答对移除。具体逻辑是当用户答错一道题时如果错题表中不存在该用户该题目的记录则插入一条。当用户再次做同一道题时答对则累计一次已掌握计数当计数达到3次时从错题本中移除该题。答错则重置计数为0并更新最近一次错误时间。这个做对3次才移除的规则参考了间隔重复学习的思路能有效防止学员偶然一次做对就以为自己学会了。错题本列表按最近错误时间倒序排列让学员优先复习最近的薄弱点。5.3 个人学习报告用数据告诉学员下一步练什么学习报告是智慧二字的集中体现。在学员首页我展示了三块内容本周刷题趋势图、各模块正确率雷达图、薄弱知识点TOP3。这些图表的数据全部来自聚合查询。比如模块正确率的计算SELECT subject, COUNT(*) AS total_count, SUM(is_correct) AS correct_count, SUM(CASE WHEN is_correct 1 THEN 1 ELSE 0 END) / COUNT(*) AS accuracy FROM practice_record WHERE user_id #{userId} AND create_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY subject;返回的列表经过二次计算组装成前端ECharts需要的JSON结构。雷达图能直观地看到学员在数量关系和资料分析这两个模块的正确率远低于其他模块薄弱知识点TOP3则从最近30天的错题中按知识点聚合取正确率最低的三个。这里我踩过一个性能坑一开始学习报告接口是实时聚合查询的practice_record表数据量小的时候没问题但数据量上去后接口响应时间越来越长尤其是一个学员刷了上万道题之后。后来我把聚合结果缓存到了Rediskey是report:{userId}:{date}TTL设置为1小时同时加了一个刷新报告按钮学员主动点击时才重新计算。这样默认页面秒开强制刷新也能兼顾数据时效性。6. 部署上线与复盘从jar包到云服务器的完整折腾记录6.1 打包部署几分钟跑起来的代价是提前解决这些配置部署部分我当时用的是最直接的方案打jar包放到云服务器上用systemd管理进程。本地打包命令mvn clean package -DskipTests生产环境的配置单独维护在application-prod.yml里和本地配置完全隔离。启动命令java -jar exam-system.jar --spring.profiles.activeprod刚开始我用nohup直接后台启动后来觉得不行进程挂了自己不会重启于是改成systemd服务。下面是简化版的service文件核心参数值得参考[Unit] DescriptionExam System Afternetwork.target [Service] Typesimple Userwww WorkingDirectory/opt/exam ExecStart/usr/bin/java -Xms256m -Xmx512m -jar /opt/exam/exam-system.jar --spring.profiles.activeprod Restarton-failure RestartSec10 [Install] WantedBymulti-user.target有一点很重要因为服务器是2核4G的低配机器JVM堆内存我给到了512MB上限避免SpringBoot 3.x JDK 17默认的堆设置把云服务器内存打满。程序里用到的Redis和MySQL都在同一台机器上内存分配必须要省着用。这个JVM参数的经验是先保守设置跑几天看监控再逐步调整。6.2 上线后遇到的两个真实问题第一个问题连接不上MySQL报错信息是关于时区的。MySQL 8.x的连接字符串如果没指定serverTimezone默认会去读服务器的系统时区而云服务器的时区如果不是Asia/Shanghai就会在建立连接时报告时区冲突。解决办法是在JDBC URL里显式加上参数spring: datasource: url: jdbc:mysql://127.0.0.1:3306/exam_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai第二个问题是上传题目的Excel文件超过默认大小被拒绝。SpringBoot的默认上传限制是1MB需求方传了一个2.3MB的题库文件直接报错。配置需要放开spring: servlet: multipart: max-file-size: 20MB max-request-size: 30MB顺手还在Nginx层也调整了client_max_body_size因为请求是先经过Nginx反向代理到SpringBoot应用的Nginx默认的限制1MB同样会拦截大文件。这种前端能选中文件但请求发不出去的问题排查时建议先看Nginx日志再看应用日志少走弯路。6.3 这套系统后续还能怎么扩展项目上线后我其实已经在脑子里排了下一期的功能优先级第一申论智能评分。当前版本申论只能人工批改题目提交后要等老师登录后台打分。现在开源的大模型API完全可以在初评阶段给学员一个参考分数和评语尽管不能作为最终成绩但对学员的即时反馈加成非常明显。第二基于协同过滤的题目推荐。目前的学习报告只能告诉学员你数量关系弱但没法告诉学员你应该做哪几道题。如果积累了足够多的用户做题数据可以跑一个简单的基于用户的协同过滤算法找到和你错题重合度最高的用户把ta做过且做对的题目推荐给你。第三题库质量运营。现在后台管理只有简单的增删改查没有题目质量指标。可以统计每道题的错误率、人均耗时如果一道题的错误率异常高且解析质量不高说明可能是题目本身有问题需要人工复核。这就是一个在线教育平台从能用到好用的分水岭。我在做这套系统的过程中最大的体会是SpringBoot本身并不难难的是把真实业务场景里的各种边界情况想清楚。考公系统看似就是一个题库加几张表但实际做下来状态机、并发控制、缓存策略、数据聚合这些问题一个都躲不掉。也正因为这样这套项目在面试里帮我扛住了不少追问。如果你正在用SpringBoot做毕业设计或者个人项目可以考虑把在线考试、在线刷题这类场景作为切入点——它既有足够的业务复杂度又不至于大到一个人做不完非常适合作为完整项目经验来沉淀。
