1. 为什么我会写一个计算机网络课程的试卷生成系统
这事儿得从带课说起。某高校的网络工程专业有一门计算机网络课，每个学期末都要出两套卷子——正考一套，补考一套。以前都是任课老师手工从题库里挑题，一份卷子有单选、多选、判断、填空、简答，加上最后的综合应用题，每次都要对着Word文档反复排版，还担心知识点覆盖不均、题目重复率太高。学生那边也有需求——考前想找点题练手，但手上只有往年纸质卷子，做完了也不知道对错。
我当时就琢磨：能不能做一个系统，把题库、组卷、试卷导出、在线练习串起来？老师登录后设定题型比例、章节范围、难度系数，点一下“生成试卷”，系统自动从题库里抽题，按预设格式排好；学生可以拿生成的卷子在线刷题，自动判分。这就是这个基于SSM的计算机网络课程试卷生成系统的由来。
这个项目麻雀虽小五脏俱全，非常适合做毕业设计或课程设计的选题。它覆盖了SSM框架整合、MySQL数据库设计、权限控制、随机组卷算法、Excel/Word文件导出这几个关键知识点。如果你正在找Java Web方向的课设题，或者想弄明白SSM项目从零搭建到上线调试的完整流程，这篇博文应该能帮你省不少力气。
2. 选型逻辑：为什么用SSM而不是Spring Boot
2.1 技术选型背后的现实考量
现在很多新项目上来就是Spring Boot，但SSM依然是高校课设、毕设里的主力军。原因很直接：教学大纲还停留在SSM阶段，很多课程设计任务书也明确要求“基于SSM框架”。从学习角度讲，SSM把配置暴露在明面上——XML里怎么写<bean>、<mvc:annotation-driven>怎么配、MyBatis的mapper映射文件怎么关联——这些底层逻辑搞明白了，回头再玩Spring Boot会觉得它只是帮你把配置自动化了而已。
这个试卷生成系统选SSM，还有一个实际原因：它需要灵活的权限拦截和事务管理。Spring MVC负责请求分发，Spring负责对象管理和声明式事务，MyBatis负责数据持久化。三者各管一段，出了问题很好定位。如果用Spring Boot，虽然起步快，但反而少了很多“手写配置”的学习过程。
2.2 系统整体的模块划分
整个系统按角色分为三类用户：管理员、教师、学生。对应的功能边界非常清晰：
- 管理员：管理教师账号、学生账号、课程信息、系统参数（比如题型分值）。
- 教师：维护题库、设计组卷策略、生成试卷、导出试卷、查看考试统计数据。
- 学生：在线答题、交卷后自动判分、查看错题记录和成绩单。
从代码层面看，这是一个典型的前后端不分离的SSM项目。JSP页面通过AJAX调后端接口，后端返回JSON数据，前端用jQuery和Bootstrap渲染。没有用Vue或者React，主要考虑是课设项目的重点在后端逻辑，前端够用就行，而且很多同学对原生JSP加jQuery更熟悉，调起来不费劲。
2.3 数据库设计的核心表结构
试卷生成系统的核心是题库和组卷策略，所以数据库设计直接决定功能能不能做深。我把表拆成了8张：
user：用户表，区分角色（管理员/教师/学生）。course：课程表，因为系统可能不止服务计算机网络这一门课，预留了扩展空间。question_bank：题库表，存题目内容、选项、答案、题型、难度、所属章节。paper_template：试卷模板表，存组卷策略，包括各题型数量、分值、难度比例。exam_paper：试卷表，一次生成的结果。exam_paper_question：试卷与题目的关联表，记录这套卷子里具体有哪些题、每题多少分。exam_record：考试记录表，学生每次答题的情况。exam_answer：答题明细表，存学生每道题的具体答案，用于判分和错题回顾。
这里有一个非常关键的细节：试卷和题目之间必须用关联表，而不能在题目表里加一个paper_id字段。原因很简单——同一道题可能同时出现在A卷和B卷里，如果直接在题目表上关联，数据就重复了。关联表还能额外记录“这道题在这张卷子里占多少分”，因为同一道题在不同卷子里完全可以设置不同的分值。
3. 组卷逻辑的实现：从随机抽取到知识点均衡
3.1 基础随机组卷的算法设计
组卷是系统的灵魂。最low的实现就是SELECT * FROM question_bank WHERE type = '单选' ORDER BY RAND() LIMIT 10，但这种写法有两个致命问题：一是数据量大时ORDER BY RAND()性能极差，全表扫描加临时排序；二是完全没有考虑知识点覆盖和难度分布，抽出来的卷子可能好几道题都考同一个知识点，难的题目扎堆，简单的题目消失。
我用的方案是“分组随机 + 策略校准”。具体分三步走：
- 先把题库里的题按“章节 + 题型 + 难度”三个维度分组。
- 根据试卷模板设定的各题型数量，按比例计算每个分组里需要抽几道题。
- 在每个分组内执行
ORDER BY RAND() LIMIT n，其中n由策略计算得出。
以计算机网络课程为例，如果试卷模板要求单选题共20道、每道1分，其中“物理层”考8道、“数据链路层”考6道、“网络层”考4道、“传输层”考2道，那么在抽题时就会先算出每个章节的配额，再逐章节随机抽取。这样生成的卷子，知识点覆盖面有保障，不会出现某章霸屏的情况。
3.2 难度系数的约束怎么做
难度控制是另一个容易忽视的坑。如果只按题型的“数量”来抽题，很容易抽出一张全员高分或全员不及格的卷子。我在paper_template表里加了一个hard_ratio字段，表示这张卷子的总体难度倾向，取值范围0到1，数值越高代表题目整体越难。
具体实现时，后台先把可用题目按难度分成三档：基础（难度系数0.3以下）、中等（0.3到0.7）、进阶（0.7以上）。然后根据模板里设定的比例分配抽题名额。比如某张卷子要求基础题占30%、中等题占50%、进阶题占20%，系统就按这个比例换算成每种题型的抽题数，再落到每个章节的配额上。
这里有个边界情况我踩过：如果题库里某一档的题目数量不够配额，系统会报“题目数量不足”的错。我当时做的是直接中断生成并提示教师补充题库，后续版本可以改成自动降级——比如中等题不够就用基础题补齐，但要在生成报告里标明。这个降级逻辑虽然简单，却很实用。
3.3 试卷排版与导出实现
在线生成的试卷需要同时支持网页预览和Word导出。网页预览用JSP渲染，把题干、选项、答案区域分开排版；Word导出则用了Apache POI操作XWPFDocument，按段落写入题目内容。
这里有一个细节值得说：计算机网络课程里有很多特殊符号和下划线填空题，比如IP地址、子网掩码的表示。直接拼字符串容易乱码，我统一在题库录入时就用UTF-8编码存库，导出时设置XWPFParagraph的字体和字符集，同时在POI里对特殊字符做了转义处理。第一次做的时候没注意，结果导出的Word里IP地址的冒号和斜杠全变成了问号，排查了半天才发现是字符集没对齐。
4. 用户权限与在线考试模块的实现思路
4.1 Spring MVC拦截器做登录与权限控制
这个系统有三类角色，权限管理用Spring MVC的HandlerInterceptor实现，没有引入Shiro或Spring Security。为什么不引入安全框架？因为课设项目的核心是业务逻辑，安全框架的配置和学习成本反而会喧宾夺主。用拦截器加一个注解就够了。
我在项目中定义了一个@RoleRequired(role = {"teacher", "admin"})注解，然后写了一个拦截器，在preHandle方法里读取当前登录用户的角色，跟注解里的要求比对，不匹配就直接返回403页面。每个Controller方法上标一下注解，权限逻辑一目了然。
拦截器还有一个附带功能：判断用户是否登录。未登录的请求统一重定向到登录页，这点在开发时容易漏——很多同学只做了登录校验，但忽略了AJAX请求被拦截后返回的是登录页HTML而不是JSON，导致前端解析失败。我在拦截器里判断了请求头X-Requested-With，如果是AJAX请求就返回JSON状态码401，前端拿到后跳转登录页，体验会好很多。
4.2 在线考试流程与自动判分的设计
学生端在线考试的核心是：开始考试时生成一份属于这个学生的试卷快照，答题过程中记录每个题目的答案，交卷后自动判分。
这里有个经验教训：试卷快照必须在学生点击“开始考试”的那一刻生成，而不是直接复用老师生成的exam_paper。原因是如果老师后来修改了试卷模板再重新生成，已经参加考试的学生数据会错乱。我的做法是：学生点击开始考试时，系统复制exam_paper和exam_paper_question到学生自己的考试记录表里，之后所有答题、判分都基于这份快照，跟老师的后续操作彻底解耦。
判分的逻辑分题型处理：
- 单选题、判断题：直接比对标准答案，对则得分，错则零分。
- 多选题：要处理“漏选得分”和“错选零分”两种模式。我做了个配置，教师可以在模板里选“严格模式”还是“宽松模式”。严格模式必须全对才得分，宽松模式漏选给一半分。
- 填空题：这个最麻烦。学生的答案经常和标准答案有细微出入，比如前后空格、大小写、中文标点。我在判分时做了预处理：去掉首尾空格、统一转半角、忽略大小写，然后再比对。这种模糊匹配不可能做到100%准确，但基本够用。
- 简答题和综合题：不做自动判分，系统把学生答案记录下来，由教师在后台批改后手动给分。这也是很实际的处理方式。
4.3 考试防作弊的轻量方案
严格意义上的在线防作弊需要摄像头监控、切屏检测、IP锁定等一堆功能，课设项目做全套不现实。我做了两个轻量措施：
一是考试期间禁止切出浏览器标签页。前端监听blur事件，切出去就提示“离开考试页面会被记录”，后台同时记录切屏次数，教师可以查看。
二是交卷时的二次确认。防止学生误点交卷导致无法挽回，点击交卷后弹窗显示“还有X道题未作答”，要求再次确认。这个细节虽然简单，但实际使用中被学生点赞最多，很多误操作都被拦住了。
5. 调试全过程：环境配置到联调阶段的坑与解法
5.1 环境搭建中最容易卡住的三个点
SSM项目的环境配置对新手很不友好，我自己前前后后带过好几个学生做类似项目，90%的人卡在同一个地方。这里把最常见的坑列一下：
JDK版本与Tomcat版本不匹配。很多同学用的是JDK 17甚至更高，但Tomcat 8.5只支持到JDK 8的目标版本，编译出来直接报UnsupportedClassVersionError。我统一用JDK 8 + Tomcat 8.5 + Maven 3.6.3，这是一个经过大量项目验证的稳定组合，不要去追新。
MyBatis的mapper XML文件放错位置。Maven项目里，默认只把src/main/resources下的文件打包到classpath。如果你的UserMapper.xml放在src/main/java目录下，而且没有在pom.xml里加<resources>配置，运行时就会报“Invalid bound statement (not found)”。这个错特别坑人，因为它编译不报错，只在调用DAO方法时才报。
数据库连接池配置里的时区问题。MySQL 8.x的连接串必须加serverTimezone=Asia/Shanghai和useSSL=false，否则启动时报时区错误或SSL握手失败。固定写法是：
jdbc:mysql://localhost:3306/exam_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai5.2 联调阶段遇到的经典Bug：中文乱码
联调时最烦的就是乱码。这个问题在试卷生成系统里尤为突出，因为题库里全是中文题干和选项。乱码可能出现在三个层次：
- 页面显示乱码：JSP页面没有设置
contentType的字符集。统一在JSP头部加<%@ page contentType="text/html;charset=UTF-8" %>。 - 后台接收参数乱码：Spring MVC接收POST请求时默认按ISO-8859-1解码。需要在
web.xml里配置CharacterEncodingFilter，并且forceEncoding设为true。 - 数据库存储乱码：建库时就要指定
utf8mb4字符集。如果你创建库时写了默认的latin1，后面连接串怎么设置都没用，因为表结构已经定死了。
5.3 试卷导出Word时的字体兼容问题
这个坑是实际调试时花了最多时间的。用POI生成Word文档，本机打开正常，换一台机器打开就发现字体变了、排版错位。原因是POI里指定的字体在另一台机器上不存在。后来我统一用“宋体 + 五号 + 首行缩进2字符”这种最保守的格式，同时给段落设置了东亚字体类型：
XWPFRun run = paragraph.createRun(); run.setFontFamily("宋体"); run.setFontSize(10); // 重点：必须同时设置EastAsia字体，否则中文可能回退到默认字体 CTRPr rpr = run.getCTR().getRPr(); if (rpr == null) { rpr = run.getCTR().addNewRPr(); } CTFonts fonts = rpr.isSetFonts() ? rpr.getFonts() : rpr.addNewFonts(); fonts.setEastAsia("宋体");这个setEastAsia的配置容易被忽略，但恰好是Word中文文档打开后是否显示正常的命门。
6. 试卷模板管理：教师侧的交互设计
6.1 所见即所得的组卷策略配置
教师创建试卷模板时，我用了一种“向导式”的表单，分三步：设置基本信息（试卷名称、考试时间、总时长）、设置题型比例（每种题型多少题、每题多少分）、设置知识点范围（从课程章节列表里勾选）。
关键在于第二步的交互：每种题型都要单独设置难度分布。比如单选题20道，可以设置基础6道、中等10道、进阶4道；但多选题只有10道，就可以设置基础2道、中等5道、进阶3道。这种灵活的配置对应到后台就是一个JSON字符串，存在paper_template表的strategy字段里，前端用JS动态生成表单，后端用Gson解析。
一开始我把策略字段设计成数据库的多个列，结果发现扩展性极差——每加一种题型就要改表结构。改成JSON存储后就灵活了，新增题型只需要在枚举类里加一个类型，前端表单动态生成，后端解析逻辑不变。
6.2 模板复用与试卷归档
教师可以把一套模板保存下来，下次直接套用，比如“计算机网络-期末正考-难度中等”这个模板每个学期都能复用。生成过的试卷会归档在历史列表里，教师可以查看以前每套试卷的题目构成、平均分、及格率。
这里有个统计数据很实用：每道题在历史试卷中被抽中的次数。我加了一个查询，统计exam_paper_question表里每个question_id被使用的次数，如果某道题连续被抽中5次以上，系统就在题库列表里给个提示“该题使用频率过高”，提醒教师要么改题、要么降低它的抽中概率。这个功能做出来之后，老师非常喜欢，因为它实实在在地解决了题库“僵尸题”的问题。
7. 学生端体验细节与成绩分析
7.1 倒计时与自动交卷的可靠性
在线考试必须有倒计时。我用了前端的setInterval每秒刷新剩余时间，同时把考试截止时间戳存在后端session里，防止学生改本地时间钻空子。
自动交卷的触发要双保险：前端倒计时归零时触发一次提交；后端在判分前校验当前时间是否超过截止时间。如果前端JS被禁用或者网络闪断，后端校验仍然能兜底。这是我做在线考试类项目的一个通用原则——前端控制体验，后端控制安全。
7.2 成绩单与错题回顾
交卷后立即展示成绩，包括总分、各题型得分率、考试用时。同时生成一份错题列表，每道错题都显示学生的答案、标准答案和题目解析。
这个错题回顾功能看起来简单，但实际价值很大，尤其是对复习备考场景。我把它做成了可以按章节筛选、按知识点筛选，学生考前可以集中刷自己薄弱的章节。我自己用这个功能刷了几套题，确实能精准定位知识盲区，比盲目刷整卷效率高不少。
7.3 班级维度的成绩统计
教师端可以按班级查看成绩分布柱状图、及格率、平均分、最高分最低分。柱状图用的是前端ECharts，从后端接口拿数据渲染。这里后端SQL要注意分组统计：
SELECT score_range, COUNT(*) FROM ( SELECT CASE WHEN score >= 90 THEN '90-100' WHEN score >= 80 THEN '80-89' WHEN score >= 70 THEN '70-79' WHEN score >= 60 THEN '60-69' ELSE '0-59' END AS score_range FROM exam_record WHERE paper_id = #{paperId} ) t GROUP BY score_range分数段统计用CASE WHEN分组是最直白的做法，不涉及额外表结构。ECharts拿到JSON数据后渲染柱状图，一个饼图一个柱图基本够用。
8. 系统部署与压测实战
8.1 打包部署到Linux服务器的完整过程
课设项目最终都要部署到服务器上演示。我的打包方式是用Maven的package命令打成WAR包，然后扔到Tomcat的webapps目录下。看似简单，但有几个配置要提前改：
- 数据库连接配置从
jdbc.properties里读取，部署时直接改这个文件，不用重新打包。 - 文件上传路径不能用项目相对路径，要配置成绝对路径。试卷导出时生成的临时Word文件，我统一放到服务器的
/data/exam_export/目录下，下载完成后定时清理。 - JSP编译缓存目录要可写。有些服务器权限设置过严，Tomcat无法在
work目录下编译JSP，启动时看不出来，一访问页面就报500。给Tomcat目录加写权限即可解决。
8.2 模拟并发考试时的性能瓶颈
我用JMeter模拟过50个学生同时交卷的场景，发现一个性能瓶颈：自动判分是串行执行的，50份卷子每份要判60道题，平均耗时0.6秒，高峰期接口响应时间飙到了5秒。
排查下来问题出在判分逻辑里频繁查询数据库——每判一道题查一次标准答案。优化方案很简单：一次查出整张试卷的所有标准答案，放进内存Map里，判分时只查Map不查库。改造后同样的并发场景，接口响应时间降到200毫秒以内。
这个优化思路在课设项目中非常实用，不需要引入Redis，不需要搞复杂缓存，就是把“循环内查询”改成“循环前查询一次”，代码改动量小，效果立竿见影。
8.3 部署后容易忽略的配置项
服务器部署还有一个需要调整的地方：Tomcat的连接数配置。默认的maxThreads是200，对课设演示来说够了，但如果评审当天所有人都同时登录，还是建议把server.xml里的maxThreads调大到400，同时把connectionTimeout保持默认。
另外一个容易踩的坑是MySQL的max_allowed_packet默认只有4MB，如果题库里导入了带图片的题目，插入时可能直接报Packet too large。我统一把课堂上用的题目以纯文本形式保存，没有支持图片题，但如果你想扩展图片题，记得先调大这个参数。
9. 代码结构复盘：哪些地方值得参考，哪些可以做得更好
9.1 分层结构与命名规范的复盘
整个项目的包结构如下，清晰分层：
controller：接收请求，校验参数，调用service，返回结果。service：业务逻辑，比如组卷算法、判分逻辑。mapper：MyBatis的DAO接口。entity：数据库实体类。dto：视图层传输对象，避免直接把实体暴露给前端。common：公共工具类、常量类、统一响应类。
我在复盘时发现一个值得改进的地方：组卷算法这种核心业务逻辑应该抽成独立的PaperGeneratorStrategy接口，然后用策略模式根据不同的模板类型实现不同算法。当时因为时间紧张，直接在一个类里写了generatePaper()方法，导致后期想扩展“按知识点权重组卷”时，不得不改动原有方法。如果当初就做好接口设计，扩展会轻松很多。
9.2 MyBatis动态SQL的使用经验
MyBatis在这个项目里的使用频率很高，最经典的是题库的多条件组合查询：
<select id="searchQuestions" resultType="com.exam.entity.QuestionBank"> SELECT * FROM question_bank <where> <if test="type != null and type != ''"> AND type = #{type} </if> <if test="chapterId != null"> AND chapter_id = #{chapterId} </if> <if test="difficulty != null"> AND difficulty = #{difficulty} </if> <if test="keyword != null and keyword != ''"> AND content LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY create_time DESC </select><where>标签配合<if>是MyBatis最实用的功能，它既解决了动态拼SQL的拼接问题，又能自动去掉多余的AND。但有一个坑必须注意：条件里的#{keyword}不能用${keyword}，否则会SQL注入。课设答辩时，评审老师大概率会问这个问题，直接作答“用了预编译防止SQL注入”能加分不少。
10. 从“能用”到“好用”：可以继续完善的几个方向
项目做完后，我复盘了哪些地方可以进一步优化。如果你是用这个项目做毕设，可以从下面几个方向里挑一个做深度扩展，答辩时就能言之有物。
方向一是引入更多题型和智能组卷算法。目前用的是分组随机抽样，可以扩展到基于遗传算法的智能组卷——把知识点覆盖、难度分布、重复率作为适应度函数，让“进化”逼近最优组卷方案。这个方向有理论深度，也有工程实现，很适合毕设。
方向二是增加试卷的难度预检测能力。目前生成试卷后无法预估整卷难度是否符合要求。可以引入经典测量理论里的项目难度系数，结合历年学生的答题记录，反向校准试卷的整体难度预估精度。这个方向贴合教育数据挖掘，工作量适中。
方向三是前端升级为前后端分离。把现有JSP页面改成Vue + Element UI，后端提供RESTful API，再把JWT认证加上。这样整个系统的技术栈更新，界面也更现代，作为毕设的展示效果会好很多。
11. 我的几条实战体会
最后说几句掏心窝的话。这个系统从零到跑通，不算题库数据录入，纯编码调试大概花了两个完整周末。中途有一半时间不是在写业务，而是在折腾环境、查乱码、修导出格式。这种体验其实很真实——SSM项目的开发难点从来不在业务本身，而在于各种配置细节和版本兼容。
如果你也准备做类似项目，我的建议是：先花半天时间把环境从零搭一遍，确保JDK、Tomcat、Maven、MySQL全部搞通再动手写代码。环境出问题时的排查速度，决定了你后面能省下多少时间。其次，数据库表结构一定要想清楚再建，尤其是试卷和题目的关系表、考试快照的设计，一旦建错，后面改动的工作量是灾难级的。最后，核心的组卷算法和判分逻辑一定自己实现一遍，不要直接抄别人的代码——这两个模块是你答辩时最有底气讲清楚的部分，也是评委最感兴趣的地方。
这套系统做完之后，我最大的收获不是代码量，而是对“一个完整的业务系统应该怎么拆解”有了真正具体的认知。从题库录入到自动组卷，从在线答题到成绩统计，每个模块看起来都不难，但把它们兜在一起还不崩，这就是SSM项目的魅力所在。希望我这篇记录能帮你少踩几个坑，顺利把项目跑起来。
