简介面向Java初学者、课程设计与毕业设计需求的Web考试系统完整工程包含题库编辑、抽题组卷、在线考试、试题分析等模块。系统现阶段已支持限时在线考试覆盖选择题、填空题、判断题三种题型并可自动判分支持通过文本文件批量导入题目和用户信息提供注册登录、修改密码、基本信息管理抽题组卷部分实现固定组卷与随机组卷两种策略并支持按内容、知识点、答案搜索题库以及题目和分数统计知识点按章节分层并以树状结构展示同时具备广播消息推送和系统设置管理功能。项目基于JDK 1.8、Tomcat 8.0、Hibernate 5.1、Struts 2.5、Spring 4.3构建整合了JFreeChart、Maven、Materialize和Font Awesome整体采用SSH框架与前端UI组件相结合的模式。压缩包体积约8.45MB已有1003人学习代码具备较高完整性可直接导入开发环境运行适合参考其数据库设计、权限控制、组卷算法及图表统计的实现思路。 做Java Web开发的人一定绕不开考试系统这个经典选题。原因很简单——它几乎覆盖了Java后端的全部核心场景复杂的表结构设计、带策略的随机组卷算法、高并发的交卷处理、多维度的数据统计分析每一个模块拿出来都能单独写一篇技术文章。这也是我当年从零撸完 java-exam 之后对整个Java技术栈的理解产生质变的原因。这篇文章不是简单的功能清单罗列而是把题库编辑、抽题组卷、在线考试、试题分析这几个核心模块从设计思路到落地实现的关键决策讲清楚尤其是我实际开发中踩过的坑、重构过的方案希望能给正在做类似Web项目的读者一些真实参考。1. 考试系统Java Web项目里最能打的全集选手1.1 为什么这个选题能吃透整个Java技术栈我最早接到这个需求时第一反应是不就是个在线答题网站吗。真正动工之后才发现考试系统的难不在某个单点功能而在它天然要求你同时处理大量相互制约的问题题库要支持多种题型和富文本组卷要兼顾随机性和难度分布在线考试要处理倒计时、断线重连、并发交卷考完之后还要把所有答题数据转化成老师能看懂的统计报表。这套组合拳打下来Java Web日常开发能遇到的技术点几乎全部覆盖。我自己做完后的体会是如果你能把一个考试系统做到稳定上线、还能扛住几百人同时考试不崩再去面那些Java基础岗位的题基本不会虚——因为八股文里的HashMap原理、事务隔离级别、索引失效这些知识点在你调优答题明细表、修并发交卷Bug的过程中早就不是背的了。1.2 系统模块的边界划分java-exam 在项目结构上拆成了六大模块题库管理、组卷管理、考试管理、在线考试、成绩管理、系统管理用户/角色/权限。这个拆分顺序是从业务流出发的——先有题才能组卷有了卷才能考考完才有成绩和分析。模块边界清楚之后前后端接口的划分就顺势而定了后期维护也基本不用来回翻代码找这段逻辑到底该放哪个包。一个值得新手注意的细节不要把权限认证和业务模块耦合在一起。我见过不少项目把当前用户是否是老师直接写在Service里结果试卷管理、成绩导出、试题分析到处都在判断角色。java-exam 的做法是基于Spring Security的注解鉴权把权限逻辑拦在Controller层之外业务Service只关心自己的数据操作清爽很多。2. 数据库设计一张题库表如何撑起整个考试体系2.1 题库表结构把选项存成JSON是我踩过的第一个坑题库表是整个系统最核心的表它设计得好不好直接决定后面组卷、阅卷、分析的复杂度。java-exam 的题目表主要字段大致是这样CREATE TABLE t_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, question_type TINYINT NOT NULL COMMENT 1-单选 2-多选 3-判断 4-填空 5-简答, subject_id BIGINT COMMENT 所属科目/课程, knowledge_point VARCHAR(64) COMMENT 知识点标签, difficulty TINYINT NOT NULL DEFAULT 3 COMMENT 难度1-5, content TEXT COMMENT 题干富文本, options TEXT COMMENT 选项JSON数组, answer TEXT COMMENT 参考答案, analysis TEXT COMMENT 答案解析, creator_id BIGINT, create_time DATETIME );这里最需要解释的是options字段。最早我按面向对象的思路单独建了一张t_question_option表觉得这样才规范结果发现纯粹给自己找麻烦——每种题型的选项数量不一样判断题甚至没有选项编辑的时候得先删旧选项再插新选项组卷查询时还要多表关联。后来直接改成JSON字符串存储选项代码里用Jackson解析成List一切变得非常顺畅。为什么这个设计是对的因为选项数据只在渲染题目和判分时才被整体使用很少有单独查询某个选项的需求这种情况用JSON列存储是性价比最高的方案。MySQL 5.7以上还支持JSON类型的索引查询也不会成为瓶颈。这不是我拍脑袋想的是踩过关联表方案之后得出的结论。2.2 试卷与考试记录的关联设计试卷本身也是一个组合数据。一张试卷包含哪些题、每题多少分、顺序怎么排我采用了t_paper试卷主表、t_paper_question试卷题目关联表、t_exam_record考试记录表、t_exam_answer答题明细表这样的四层设计t_paper保存试卷名称、总分、考试时长、组卷策略参数。t_paper_question保存题目ID、题型、分值、排序号让试卷和题库解耦——即便是随机组卷一旦生成试卷就固化了题目快照防止题库题目被修改后影响历史试卷。t_exam_record一次考试会话记录考生、试卷、开始时间、交卷时间、总得分、状态。t_exam_answer每道题的作答明细记录题目ID、考生选项/答案文本、判分结果、得分。题目快照这一点非常重要。我遇到过真实的生产事故老师在考试中途编辑了某道题的答案结果更早提交的学生按照新答案被重新判分。所以t_paper_question里必须冗余存储一份题目当时的题干、选项和答案快照而不是只存一个question_id。2.3 索引与事务的细节考量在线考试场景下最频繁的查询是加载一份试卷的所有题目和保存一题答案。前者我建了联合索引(paper_id, sort_no)后者在t_exam_answer上建了(exam_record_id, question_id)唯一索引既保证了一个考生对一道题只有一条作答记录又让更新答案走索引不锁全表。事务方面也要区分场景组卷写多张表必须用事务答题保存单行更新不需要长事务。我见过有人在答题保存的Service方法上直接加Transactional结果并发高的时候数据库连接池被占满系统直接雪崩。答题保存就老老实实做单条update把事务粒度缩到最小。3. 题库编辑从富文本到答案校验的实用处理3.1 富文本存储与编辑器的选型题干的输入不是简单文本框尤其数学题要公式、编程题要代码块所以编辑器我选了支持公式和代码高亮的富文本方案。这里有个细节富文本内容必须做XSS过滤。题库编辑是面向教师的看起来内部系统不需要考虑安全但一旦考试系统部署到公网或者被低权限账号访问未过滤的富文本可能被注入恶意脚本。我的做法是在后端统一做白名单过滤只允许p、img、pre、code、span、strong等常用标签所有事件属性和javascript:协议一律拦截。这个过滤一定要放在后端不要信前端校验因为请求是可以直接构造的。3.2 答案校验的边界情况不同题型的答案格式差别很大我在t_question里统一用TEXT存储但校验逻辑按题型分支处理单选题答案必须是选项JSON里的某一个value不能随便填。多选题答案必须是选项value的数组且至少选两项除非出题人故意允许单选。判断题答案固定为true或false。填空题允许多个空答案用||分隔做模糊匹配时还要忽略首尾空格。简答题无标准答案只保存参考答案交由人工阅卷。还有一个容易被忽略的点修改题目的答案后历史考试中已经落库的t_exam_answer判分结果不能跟着变。前面说了题目快照解决这个问题同时教师在编辑题目时系统要给出提示修改答案仅对之后新生成的试卷生效避免老师误以为历史成绩也会更新。4. 抽题组卷随机之外还要策略4.1 从固定试卷到随机组卷的演进最初的版本只支持固定组卷——老师像拼Word文档一样一道题一道题往试卷里加。功能做了之后被吐槽得最狠因为每次出模拟卷都要手动选题工作量大不说还容易出现两张卷子难度不均的情况。随机组卷的需求就出来了老师只需要定总题数、各题型数量、知识点范围、平均难度系统自动从题库里抽题。但随机不能是简单的ORDER BY RAND()——那条SQL在数据量大的时候能把数据库拖垮而且抽出来的题可能知识点评分严重失衡。4.2 按知识点与难度比例参与的组卷算法我给组卷加了策略参数核心是按知识点分组、组内按难度配额抽题的算法根据老师选定的知识点范围把符合条件的题目按知识点分组。在每个知识点分组内再按难度1~5分组。根据老师设置的难度权重比如简单20% 中等60% 困难20%计算每个难度档需要抽取的题数。组内采用洗牌取前N的方式随机抽取而不是每次都ORDER BY RAND()。难度配额的公式大概是某个知识点下抽取的题数 该知识点目标题数 × 该难度档占比四舍五入后做尾差校正保证总数精确。// 按知识点难度分组后从每个桶中随机抽取指定数量 public ListQuestion pickQuestions(MapString, MapInteger, ListQuestion buckets, MapString, Integer knowledgePointCount, MapInteger, Integer difficultyQuota) { ListQuestion result new ArrayList(); for (Map.EntryString, Integer kpEntry : knowledgePointCount.entrySet()) { MapInteger, ListQuestion diffBucket buckets.get(kpEntry.getKey()); int need kpEntry.getValue(); for (Map.EntryInteger, Integer quota : difficultyQuota.entrySet()) { int needThisDiff Math.round(need * (quota.getValue() / 100f)); ListQuestion pool diffBucket.get(quota.getKey()); Collections.shuffle(pool); result.addAll(pool.subList(0, Math.min(needThisDiff, pool.size()))); } } // 若部分难度档题目不足用同知识点其他难度补齐 fillRemaining(result, buckets, difficultyQuota); return result; }这道fillRemaining是必须有的兜底逻辑。题库里很可能某个难度档的题不够抽如果不补齐生成的试卷题数就少了。补齐的策略是优先补相近难度难度±1再不行就同知识点内随意补齐。4.3 组卷结果的预览与存卷组卷算法跑完之后不能直接发布。我做了预览试卷环节老师可以看到这次随机生成的试卷全貌不满意的点重新生成再抽一次满意了才正式落库。落库时把每道题的快照写入t_paper_question之后无论题库怎么改这份卷子都不受影响。这个先预览后发布的交互我强烈推荐保留它解决了一个信任问题——老师不信任纯黑盒随机给一次确认机会能减少很多后期投诉。5. 在线考试倒计时、断点续答与防作弊5.1 倒计时的状态管理绝对不能只信前端考试进行中最核心的是时间状态管理。我踩过一个典型的坑一开始倒计时放在前端用JavaScript的setInterval每秒减一到0就自动交卷。结果有学生打开浏览器开发者工具改一下变量时间就冻住了。后来改成前端只负责显示剩余时间真正的考试截止时间由后端基于exam_record.start_time paper.duration计算。每个关键接口保存答案、交卷都会校验当前时间是否超过截止时间超时直接拒绝并触发自动交卷。前端的倒计时纯粹是给考生看的进度条。5.2 答案自动暂存与断线续答考试过程中考生可能会刷新页面、断网、甚至换电脑。如果答案存在内存变量里刷新就全没了这种体验会让人直接炸。我在设计上做了两层保障答案实时保存考生每做一题点击答题后防抖2秒前端异步调一次保存答案接口后端upsert到t_exam_answer。进入考试时恢复现场后端提供一个loadMyAnswers接口返回当前考试记录下所有已保存的答案前端用考生ID考试记录ID做Key刷新后全部回填。防抖保存这块要注意控制频率不然一道单选题选了又改改又选几秒钟能发十几个请求。5.3 交卷时的并发与校验处理交卷是考试系统并发风险最高的地方。正常情况下一个考生交卷只会触发一次请求但如果有学生重复点击、或者前端请求超时重试就可能出现多个交卷请求同时打到后端。如果不去重成绩可能被计算两遍甚至出现重复交卷异常。我的方案是用数据库层面的状态机控制t_exam_record的status字段有ONGOING考试中、SUBMITTED已交卷、TIMEOUT超时自动交卷三种状态。交卷接口里先执行一条条件更新UPDATE t_exam_record SET status SUBMITTED, submit_time NOW() WHERE id ? AND status ONGOING如果受影响行数为0说明考试记录已经被交过卷了直接返回已交卷不重复计算成绩。这道乐观锁式的条件更新比在代码里先select再update要可靠得多也天然规避了并发重复提交的问题。自动交卷我另外做了一个定时任务兜底每分钟扫描一次超过截止时间仍处于ONGOING状态的考试记录强制置为TIMEOUT并触发判分。为什么要定时任务而不完全依赖接口校验因为有些考生考到一半直接关浏览器跑了永远不会再发请求这时只能靠后端定时任务把状态流转掉。6. 试题分析把考试数据变成教学的决策依据6.1 正确率、难度与区分度的实际算法试题分析模块最基础的三张报表整体成绩分布、单题正确率、知识点掌握度。这三个数字看起来简单计算口径却要注意。单题正确率 该题得分不低于满分的考生数 ÷ 参加考试且作答了该题的考生数并不是除以该场考试全部考生人数——因为有些考生可能因为随机组卷根本没抽到这道题。java-exam 实际计算时分母用的是t_exam_answer里对该题有作答记录的人数这样才能准确反映题目本身的通过率。区分度是一个更进阶的指标把考生按总分降序排列取前27%作为高分组、后27%作为低分组区分度 高分组该题平均得分率 - 低分组该题平均得分率。区间在0.4以上说明题目区分度优秀低于0.2可以考虑是否是题目过难、表述有歧义或者答案设置不合理。6.2 分析结果的可视化与成绩导出分析数据最终要落到界面上我用的是ECharts渲染成绩分布直方图、知识点雷达图、难度评分折线图。图表这类纯展示组件关键是把后端算好的数据以DTO形式返回格式尽量贴合图表库的输入不要在前端做过多数据组装否则页面一卡就说不清是后端慢还是前端运算慢。成绩导出我最初用POI生成.xlsx后来发现试卷分析更常见的场景是导出学生成绩总表和每道题的得分明细表。Excel模板里要注意合并单元格、冻结首行这类细节用POI的SXSSFWorkbook处理几万行数据才不卡。如果你的导出场景只有几百行用传统的XSSFWorkbook就行没必要上来就上流式API。7. 部署与性能优化的实战心得7.1 服务器选型与连接池参数java-exam 的部署架构我用了典型的单体Web应用方案一台应用服务器跑Spring Boot 一台MySQL。对于中小规模考试几百人同场这个配置绰绰有余不需要一上来就上微服务。真正决定系统上限的往往是数据库连接池和Tomcat线程池的配合。HikariCP的maximum-pool-size我最终定在20Tomcat的max-threads定在200。这个比例不是拍脑袋定的——线程池里的业务请求最终都要拿数据库连接如果Tomcat线程数远大于连接池上限多余的线程只能排队等连接反而徒增上下文切换。当一个请求90%的时间都在等数据库连接时瓶颈就不在CPU而在连接池。这里的调优思路是让连接池的并发连接数略小于数据库能稳定承受的上限让Tomcat线程池的线程数略大于连接池的2~3倍即可。7.2 题库检索与答题明细的分页优化题库管理首页通常要支持按题型、知识点、难度组合筛选数据量上来之后简单的LIKE %keyword%会导致全表扫描。优化的常规手段是对knowledge_point、difficulty建联合索引同时把题干搜索改成全文索引或者落到Elasticsearch——但对于中小项目MySQL的全文索引已经够用没必要为了一个搜索功能单独引入一套ES集群。答题明细表是增长最快的表一场500人的考试会产生几万条t_exam_answer。我在分页查询明细时做了垂直拆分列表页只查id、question_id、score这几个轻量字段点击查看详情再加载answer_content、question_content这类大字段。这样列表接口的响应体小、查询快用户体感也好很多。8. 在线考试场景下的安全与异常兜底8.1 防作弊不能只靠前端限制考试系统的安全防的是切屏、多端登录、接口恶意刷题这类行为。纯前端的visibilitychange监听只能提醒不能拦截真正的安全防线要放在后端接口上IP用户考试记录绑定同一个考试记录如果发现两个不同IP在交替提交答案标记异常。切屏记录前端把切屏次数上报后端记录到t_exam_record的临时字段供老师查看。敏感接口限流保存答案接口做频控比如30秒内最多提交20次超过则提示操作过于频繁。这只是轻度限制不要设得太激进否则学生改选项时多点几次就被封了。这些设计的目的不是把系统做成全网最严防作弊平台而是建立一道基础防线同时给监考老师提供证据参考这在真实的在线考试场景里是刚需。8.2 异常兜底与重试机制在线考试最怕莫名少了两道题、答案丢了、交卷失败。我加的兜底方案有两个一个是考试会话心跳。考生进入考试后前端每30秒调一次heartbeat接口后端更新心跳时间。一旦超过2分钟没心跳系统在后台标记该考生可能已断线但不主动踢出考生重新连上时根据t_exam_answer恢复现场继续作答。另一个是交卷失败的重试幂等。交卷接口前面提到了条件更新保证幂等即使前端因为网络超时重试了三次最终也只计算一次成绩不会重复判分。这个设计在模拟并发压测时帮我挡掉了大量重复计算的Bug属于最值得提前做好的基础防护。一个Java Web开发者的职业价值往往就体现在这些平时看不见、关键时刻救命的兜底设计里——考试系统做完一遍这类意识就会真正长在你身上。最后再说一点个人心得java-exam 这套系统做完之后我最大收获不是我会做考试系统了而是彻底摸清了从需求分析、表设计、接口联调到部署上线的完整链路。如果你也正在做类似的Java Web项目建议在动手前先花时间把数据模型想清楚尤其是快照、状态机、幂等这三个概念——它们会在后续几乎每个模块里反复出现。项目写到最后拼的从来不是某个炫技的算法而是这些基础设计是否扎实。本文还有配套的精品资源点击获取 Java Web考试系统实战：从题库设计到高并发在线考试
简介面向Java初学者、课程设计与毕业设计需求的Web考试系统完整工程包含题库编辑、抽题组卷、在线考试、试题分析等模块。系统现阶段已支持限时在线考试覆盖选择题、填空题、判断题三种题型并可自动判分支持通过文本文件批量导入题目和用户信息提供注册登录、修改密码、基本信息管理抽题组卷部分实现固定组卷与随机组卷两种策略并支持按内容、知识点、答案搜索题库以及题目和分数统计知识点按章节分层并以树状结构展示同时具备广播消息推送和系统设置管理功能。项目基于JDK 1.8、Tomcat 8.0、Hibernate 5.1、Struts 2.5、Spring 4.3构建整合了JFreeChart、Maven、Materialize和Font Awesome整体采用SSH框架与前端UI组件相结合的模式。压缩包体积约8.45MB已有1003人学习代码具备较高完整性可直接导入开发环境运行适合参考其数据库设计、权限控制、组卷算法及图表统计的实现思路。 做Java Web开发的人一定绕不开考试系统这个经典选题。原因很简单——它几乎覆盖了Java后端的全部核心场景复杂的表结构设计、带策略的随机组卷算法、高并发的交卷处理、多维度的数据统计分析每一个模块拿出来都能单独写一篇技术文章。这也是我当年从零撸完 java-exam 之后对整个Java技术栈的理解产生质变的原因。这篇文章不是简单的功能清单罗列而是把题库编辑、抽题组卷、在线考试、试题分析这几个核心模块从设计思路到落地实现的关键决策讲清楚尤其是我实际开发中踩过的坑、重构过的方案希望能给正在做类似Web项目的读者一些真实参考。1. 考试系统Java Web项目里最能打的全集选手1.1 为什么这个选题能吃透整个Java技术栈我最早接到这个需求时第一反应是不就是个在线答题网站吗。真正动工之后才发现考试系统的难不在某个单点功能而在它天然要求你同时处理大量相互制约的问题题库要支持多种题型和富文本组卷要兼顾随机性和难度分布在线考试要处理倒计时、断线重连、并发交卷考完之后还要把所有答题数据转化成老师能看懂的统计报表。这套组合拳打下来Java Web日常开发能遇到的技术点几乎全部覆盖。我自己做完后的体会是如果你能把一个考试系统做到稳定上线、还能扛住几百人同时考试不崩再去面那些Java基础岗位的题基本不会虚——因为八股文里的HashMap原理、事务隔离级别、索引失效这些知识点在你调优答题明细表、修并发交卷Bug的过程中早就不是背的了。1.2 系统模块的边界划分java-exam 在项目结构上拆成了六大模块题库管理、组卷管理、考试管理、在线考试、成绩管理、系统管理用户/角色/权限。这个拆分顺序是从业务流出发的——先有题才能组卷有了卷才能考考完才有成绩和分析。模块边界清楚之后前后端接口的划分就顺势而定了后期维护也基本不用来回翻代码找这段逻辑到底该放哪个包。一个值得新手注意的细节不要把权限认证和业务模块耦合在一起。我见过不少项目把当前用户是否是老师直接写在Service里结果试卷管理、成绩导出、试题分析到处都在判断角色。java-exam 的做法是基于Spring Security的注解鉴权把权限逻辑拦在Controller层之外业务Service只关心自己的数据操作清爽很多。2. 数据库设计一张题库表如何撑起整个考试体系2.1 题库表结构把选项存成JSON是我踩过的第一个坑题库表是整个系统最核心的表它设计得好不好直接决定后面组卷、阅卷、分析的复杂度。java-exam 的题目表主要字段大致是这样CREATE TABLE t_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, question_type TINYINT NOT NULL COMMENT 1-单选 2-多选 3-判断 4-填空 5-简答, subject_id BIGINT COMMENT 所属科目/课程, knowledge_point VARCHAR(64) COMMENT 知识点标签, difficulty TINYINT NOT NULL DEFAULT 3 COMMENT 难度1-5, content TEXT COMMENT 题干富文本, options TEXT COMMENT 选项JSON数组, answer TEXT COMMENT 参考答案, analysis TEXT COMMENT 答案解析, creator_id BIGINT, create_time DATETIME );这里最需要解释的是options字段。最早我按面向对象的思路单独建了一张t_question_option表觉得这样才规范结果发现纯粹给自己找麻烦——每种题型的选项数量不一样判断题甚至没有选项编辑的时候得先删旧选项再插新选项组卷查询时还要多表关联。后来直接改成JSON字符串存储选项代码里用Jackson解析成List一切变得非常顺畅。为什么这个设计是对的因为选项数据只在渲染题目和判分时才被整体使用很少有单独查询某个选项的需求这种情况用JSON列存储是性价比最高的方案。MySQL 5.7以上还支持JSON类型的索引查询也不会成为瓶颈。这不是我拍脑袋想的是踩过关联表方案之后得出的结论。2.2 试卷与考试记录的关联设计试卷本身也是一个组合数据。一张试卷包含哪些题、每题多少分、顺序怎么排我采用了t_paper试卷主表、t_paper_question试卷题目关联表、t_exam_record考试记录表、t_exam_answer答题明细表这样的四层设计t_paper保存试卷名称、总分、考试时长、组卷策略参数。t_paper_question保存题目ID、题型、分值、排序号让试卷和题库解耦——即便是随机组卷一旦生成试卷就固化了题目快照防止题库题目被修改后影响历史试卷。t_exam_record一次考试会话记录考生、试卷、开始时间、交卷时间、总得分、状态。t_exam_answer每道题的作答明细记录题目ID、考生选项/答案文本、判分结果、得分。题目快照这一点非常重要。我遇到过真实的生产事故老师在考试中途编辑了某道题的答案结果更早提交的学生按照新答案被重新判分。所以t_paper_question里必须冗余存储一份题目当时的题干、选项和答案快照而不是只存一个question_id。2.3 索引与事务的细节考量在线考试场景下最频繁的查询是加载一份试卷的所有题目和保存一题答案。前者我建了联合索引(paper_id, sort_no)后者在t_exam_answer上建了(exam_record_id, question_id)唯一索引既保证了一个考生对一道题只有一条作答记录又让更新答案走索引不锁全表。事务方面也要区分场景组卷写多张表必须用事务答题保存单行更新不需要长事务。我见过有人在答题保存的Service方法上直接加Transactional结果并发高的时候数据库连接池被占满系统直接雪崩。答题保存就老老实实做单条update把事务粒度缩到最小。3. 题库编辑从富文本到答案校验的实用处理3.1 富文本存储与编辑器的选型题干的输入不是简单文本框尤其数学题要公式、编程题要代码块所以编辑器我选了支持公式和代码高亮的富文本方案。这里有个细节富文本内容必须做XSS过滤。题库编辑是面向教师的看起来内部系统不需要考虑安全但一旦考试系统部署到公网或者被低权限账号访问未过滤的富文本可能被注入恶意脚本。我的做法是在后端统一做白名单过滤只允许p、img、pre、code、span、strong等常用标签所有事件属性和javascript:协议一律拦截。这个过滤一定要放在后端不要信前端校验因为请求是可以直接构造的。3.2 答案校验的边界情况不同题型的答案格式差别很大我在t_question里统一用TEXT存储但校验逻辑按题型分支处理单选题答案必须是选项JSON里的某一个value不能随便填。多选题答案必须是选项value的数组且至少选两项除非出题人故意允许单选。判断题答案固定为true或false。填空题允许多个空答案用||分隔做模糊匹配时还要忽略首尾空格。简答题无标准答案只保存参考答案交由人工阅卷。还有一个容易被忽略的点修改题目的答案后历史考试中已经落库的t_exam_answer判分结果不能跟着变。前面说了题目快照解决这个问题同时教师在编辑题目时系统要给出提示修改答案仅对之后新生成的试卷生效避免老师误以为历史成绩也会更新。4. 抽题组卷随机之外还要策略4.1 从固定试卷到随机组卷的演进最初的版本只支持固定组卷——老师像拼Word文档一样一道题一道题往试卷里加。功能做了之后被吐槽得最狠因为每次出模拟卷都要手动选题工作量大不说还容易出现两张卷子难度不均的情况。随机组卷的需求就出来了老师只需要定总题数、各题型数量、知识点范围、平均难度系统自动从题库里抽题。但随机不能是简单的ORDER BY RAND()——那条SQL在数据量大的时候能把数据库拖垮而且抽出来的题可能知识点评分严重失衡。4.2 按知识点与难度比例参与的组卷算法我给组卷加了策略参数核心是按知识点分组、组内按难度配额抽题的算法根据老师选定的知识点范围把符合条件的题目按知识点分组。在每个知识点分组内再按难度1~5分组。根据老师设置的难度权重比如简单20% 中等60% 困难20%计算每个难度档需要抽取的题数。组内采用洗牌取前N的方式随机抽取而不是每次都ORDER BY RAND()。难度配额的公式大概是某个知识点下抽取的题数 该知识点目标题数 × 该难度档占比四舍五入后做尾差校正保证总数精确。// 按知识点难度分组后从每个桶中随机抽取指定数量 public ListQuestion pickQuestions(MapString, MapInteger, ListQuestion buckets, MapString, Integer knowledgePointCount, MapInteger, Integer difficultyQuota) { ListQuestion result new ArrayList(); for (Map.EntryString, Integer kpEntry : knowledgePointCount.entrySet()) { MapInteger, ListQuestion diffBucket buckets.get(kpEntry.getKey()); int need kpEntry.getValue(); for (Map.EntryInteger, Integer quota : difficultyQuota.entrySet()) { int needThisDiff Math.round(need * (quota.getValue() / 100f)); ListQuestion pool diffBucket.get(quota.getKey()); Collections.shuffle(pool); result.addAll(pool.subList(0, Math.min(needThisDiff, pool.size()))); } } // 若部分难度档题目不足用同知识点其他难度补齐 fillRemaining(result, buckets, difficultyQuota); return result; }这道fillRemaining是必须有的兜底逻辑。题库里很可能某个难度档的题不够抽如果不补齐生成的试卷题数就少了。补齐的策略是优先补相近难度难度±1再不行就同知识点内随意补齐。4.3 组卷结果的预览与存卷组卷算法跑完之后不能直接发布。我做了预览试卷环节老师可以看到这次随机生成的试卷全貌不满意的点重新生成再抽一次满意了才正式落库。落库时把每道题的快照写入t_paper_question之后无论题库怎么改这份卷子都不受影响。这个先预览后发布的交互我强烈推荐保留它解决了一个信任问题——老师不信任纯黑盒随机给一次确认机会能减少很多后期投诉。5. 在线考试倒计时、断点续答与防作弊5.1 倒计时的状态管理绝对不能只信前端考试进行中最核心的是时间状态管理。我踩过一个典型的坑一开始倒计时放在前端用JavaScript的setInterval每秒减一到0就自动交卷。结果有学生打开浏览器开发者工具改一下变量时间就冻住了。后来改成前端只负责显示剩余时间真正的考试截止时间由后端基于exam_record.start_time paper.duration计算。每个关键接口保存答案、交卷都会校验当前时间是否超过截止时间超时直接拒绝并触发自动交卷。前端的倒计时纯粹是给考生看的进度条。5.2 答案自动暂存与断线续答考试过程中考生可能会刷新页面、断网、甚至换电脑。如果答案存在内存变量里刷新就全没了这种体验会让人直接炸。我在设计上做了两层保障答案实时保存考生每做一题点击答题后防抖2秒前端异步调一次保存答案接口后端upsert到t_exam_answer。进入考试时恢复现场后端提供一个loadMyAnswers接口返回当前考试记录下所有已保存的答案前端用考生ID考试记录ID做Key刷新后全部回填。防抖保存这块要注意控制频率不然一道单选题选了又改改又选几秒钟能发十几个请求。5.3 交卷时的并发与校验处理交卷是考试系统并发风险最高的地方。正常情况下一个考生交卷只会触发一次请求但如果有学生重复点击、或者前端请求超时重试就可能出现多个交卷请求同时打到后端。如果不去重成绩可能被计算两遍甚至出现重复交卷异常。我的方案是用数据库层面的状态机控制t_exam_record的status字段有ONGOING考试中、SUBMITTED已交卷、TIMEOUT超时自动交卷三种状态。交卷接口里先执行一条条件更新UPDATE t_exam_record SET status SUBMITTED, submit_time NOW() WHERE id ? AND status ONGOING如果受影响行数为0说明考试记录已经被交过卷了直接返回已交卷不重复计算成绩。这道乐观锁式的条件更新比在代码里先select再update要可靠得多也天然规避了并发重复提交的问题。自动交卷我另外做了一个定时任务兜底每分钟扫描一次超过截止时间仍处于ONGOING状态的考试记录强制置为TIMEOUT并触发判分。为什么要定时任务而不完全依赖接口校验因为有些考生考到一半直接关浏览器跑了永远不会再发请求这时只能靠后端定时任务把状态流转掉。6. 试题分析把考试数据变成教学的决策依据6.1 正确率、难度与区分度的实际算法试题分析模块最基础的三张报表整体成绩分布、单题正确率、知识点掌握度。这三个数字看起来简单计算口径却要注意。单题正确率 该题得分不低于满分的考生数 ÷ 参加考试且作答了该题的考生数并不是除以该场考试全部考生人数——因为有些考生可能因为随机组卷根本没抽到这道题。java-exam 实际计算时分母用的是t_exam_answer里对该题有作答记录的人数这样才能准确反映题目本身的通过率。区分度是一个更进阶的指标把考生按总分降序排列取前27%作为高分组、后27%作为低分组区分度 高分组该题平均得分率 - 低分组该题平均得分率。区间在0.4以上说明题目区分度优秀低于0.2可以考虑是否是题目过难、表述有歧义或者答案设置不合理。6.2 分析结果的可视化与成绩导出分析数据最终要落到界面上我用的是ECharts渲染成绩分布直方图、知识点雷达图、难度评分折线图。图表这类纯展示组件关键是把后端算好的数据以DTO形式返回格式尽量贴合图表库的输入不要在前端做过多数据组装否则页面一卡就说不清是后端慢还是前端运算慢。成绩导出我最初用POI生成.xlsx后来发现试卷分析更常见的场景是导出学生成绩总表和每道题的得分明细表。Excel模板里要注意合并单元格、冻结首行这类细节用POI的SXSSFWorkbook处理几万行数据才不卡。如果你的导出场景只有几百行用传统的XSSFWorkbook就行没必要上来就上流式API。7. 部署与性能优化的实战心得7.1 服务器选型与连接池参数java-exam 的部署架构我用了典型的单体Web应用方案一台应用服务器跑Spring Boot 一台MySQL。对于中小规模考试几百人同场这个配置绰绰有余不需要一上来就上微服务。真正决定系统上限的往往是数据库连接池和Tomcat线程池的配合。HikariCP的maximum-pool-size我最终定在20Tomcat的max-threads定在200。这个比例不是拍脑袋定的——线程池里的业务请求最终都要拿数据库连接如果Tomcat线程数远大于连接池上限多余的线程只能排队等连接反而徒增上下文切换。当一个请求90%的时间都在等数据库连接时瓶颈就不在CPU而在连接池。这里的调优思路是让连接池的并发连接数略小于数据库能稳定承受的上限让Tomcat线程池的线程数略大于连接池的2~3倍即可。7.2 题库检索与答题明细的分页优化题库管理首页通常要支持按题型、知识点、难度组合筛选数据量上来之后简单的LIKE %keyword%会导致全表扫描。优化的常规手段是对knowledge_point、difficulty建联合索引同时把题干搜索改成全文索引或者落到Elasticsearch——但对于中小项目MySQL的全文索引已经够用没必要为了一个搜索功能单独引入一套ES集群。答题明细表是增长最快的表一场500人的考试会产生几万条t_exam_answer。我在分页查询明细时做了垂直拆分列表页只查id、question_id、score这几个轻量字段点击查看详情再加载answer_content、question_content这类大字段。这样列表接口的响应体小、查询快用户体感也好很多。8. 在线考试场景下的安全与异常兜底8.1 防作弊不能只靠前端限制考试系统的安全防的是切屏、多端登录、接口恶意刷题这类行为。纯前端的visibilitychange监听只能提醒不能拦截真正的安全防线要放在后端接口上IP用户考试记录绑定同一个考试记录如果发现两个不同IP在交替提交答案标记异常。切屏记录前端把切屏次数上报后端记录到t_exam_record的临时字段供老师查看。敏感接口限流保存答案接口做频控比如30秒内最多提交20次超过则提示操作过于频繁。这只是轻度限制不要设得太激进否则学生改选项时多点几次就被封了。这些设计的目的不是把系统做成全网最严防作弊平台而是建立一道基础防线同时给监考老师提供证据参考这在真实的在线考试场景里是刚需。8.2 异常兜底与重试机制在线考试最怕莫名少了两道题、答案丢了、交卷失败。我加的兜底方案有两个一个是考试会话心跳。考生进入考试后前端每30秒调一次heartbeat接口后端更新心跳时间。一旦超过2分钟没心跳系统在后台标记该考生可能已断线但不主动踢出考生重新连上时根据t_exam_answer恢复现场继续作答。另一个是交卷失败的重试幂等。交卷接口前面提到了条件更新保证幂等即使前端因为网络超时重试了三次最终也只计算一次成绩不会重复判分。这个设计在模拟并发压测时帮我挡掉了大量重复计算的Bug属于最值得提前做好的基础防护。一个Java Web开发者的职业价值往往就体现在这些平时看不见、关键时刻救命的兜底设计里——考试系统做完一遍这类意识就会真正长在你身上。最后再说一点个人心得java-exam 这套系统做完之后我最大收获不是我会做考试系统了而是彻底摸清了从需求分析、表设计、接口联调到部署上线的完整链路。如果你也正在做类似的Java Web项目建议在动手前先花时间把数据模型想清楚尤其是快照、状态机、幂等这三个概念——它们会在后续几乎每个模块里反复出现。项目写到最后拼的从来不是某个炫技的算法而是这些基础设计是否扎实。本文还有配套的精品资源点击获取