简介试题库管理系统是一份基于Qt框架与SQL数据库的课程设计完整资源面向高校计算机专业学生及需要完成数据库课程设计的开发者可帮助解决题库管理、随机组卷、成绩统计与数据持久化等典型问题。资源共47个文件压缩包约1.29MB源码部分包含5个cpp、7个h、3个ui及pro工程文件可直接编译运行数据库方面带有1个sql脚本便于建库建表和数据初始化另有5个qss样式表、12个png界面截图以及3份docx与1份doc文档涵盖任务书、课程设计报告、数据流图与模块实现说明可清晰还原从需求分析、概念结构设计到逻辑结构设计的完整过程。目前已有1706人学习下载适合作课程设计选题参考、答辩材料范本也能用于练习Qt与SQL的联动开发。 很多同学把试题库管理系统当普通 CRUD 项目来练手我一开始也是这么干的。结果做完了才发现一个致命问题系统能跑通但没有任何人愿意往里传题。题目录不进去题库就是空的题库是空的组卷、刷题全是空中楼阁。这篇博文把我从零做一个可用的题库管理系统的完整过程写出来重点不是某个框架的 API而是题目怎么建模、组卷规则怎么落库、Word 里的存量题怎么批量进来以及多人共用一套系统时权限怎么隔离。适合正在做毕设、课程设计或者想给学校、机构搭一套内部题库工具的朋友参考。1. 先定义清楚边界题库系统要解决的是「攒题难、出卷乱」1.1 我划掉的功能在线考试和自动阅卷很多人拿到这个需求的第一反应是做完整在线考试平台定时下发、防切屏、自动判分、成绩排名一套全上。我第一版把这些全部划掉了只保留四件事题目管理、组卷、批量导入导出、权限隔离。这里有个很现实的理由题库系统的核心价值在于把题目这种数据资产沉淀下来而出题、审题、整理格式才是最耗人力的环节。老师们手里拿着一堆 Word 试卷想要的是「能把这些题快速存进去然后按知识点抽出来组一张新卷子」至于学生怎么在线考那是消费题库的另一种方式等题量攒起来再做完全来得及。我把第一版功能边界整理成了一张表建议你也照这个思路控制范围模块第一版做不做判断理由题目增删改查做基础中的基础手工组卷做老师最常见的使用路径按知识点/难度规则抽题做区别于「大号 Excel」的核心功能Excel 批量导入模板做决定存量题能不能进得来Word 试卷自动解析做最小可用版能解析纯文本和图片不追求完美在线考试不做放到二期先解决数据从哪来自动判分不做题型复杂判分规则容易失控成绩统计报表不做没有考试数据支撑做了也是空壳明确边界之后整个系统的数据模型、接口设计都会清晰很多自己写代码不会被「万一以后要加 XX 功能」卡住。1.2 技术选型为什么是 Spring Boot Vue而不是「全家桶」技术栈我选了 Spring Boot 2.7 MyBatis-Plus MySQL 8前端 Vue 3 Element Plus权限用 Sa-Token。这套组合在中小型管理系统里属于最稳妥的方案资料全、能搜到的坑多、一个人也维护得住。不用 Redis、不用 Elasticsearch、不用微服务。题目量到几十万之前MySQL 的普通索引加几个优化手段完全够用真要上全文检索等系统活过一年再引入也不迟。Redis 在这里最多用来做缓存热点题属于优化而非必选项。选型这件事少即是多。Spring Boot Vue 的好处是万一项目要交接给下一个同学对方大概率也用过这套技术栈学习成本低。2. 题目表设计多态题型靠一个 JSON 字段撑住了2.1 一张表还是多张表我选一张主表加 JSON 的原因题目这玩意儿最麻烦的地方是它的「长相」差异太大。单选题有选项 ABCD判断题只有对和错填空题有几个空简答题没有标准选项只有参考答案。如果按教科书做法拆题表、选项表、答案表后面每次查询都要 JOIN 四五张表组卷时组装对象更是噩梦。我用了一张主表把题型的公共字段抽出来把「题型特有属性」塞进 JSON 字段。核心表结构长这样CREATE TABLE question ( id BIGINT AUTO_INCREMENT PRIMARY KEY, question_type TINYINT NOT NULL COMMENT 1单选 2多选 3判断 4填空 5简答, content MEDIUMTEXT NOT NULL COMMENT 题干富文本HTML, options JSON NULL COMMENT 选项JSON如[{key:A,content:...}], answer VARCHAR(512) NOT NULL COMMENT 答案按题型约定序列化, analysis MEDIUMTEXT NULL COMMENT 答案解析, difficulty TINYINT NOT NULL DEFAULT 3 COMMENT 难度1-5, subject_id BIGINT NOT NULL COMMENT 所属科目, knowledge_id BIGINT NULL COMMENT 所属知识点, owner_id BIGINT NOT NULL COMMENT 创建人, is_public TINYINT NOT NULL DEFAULT 0 COMMENT 0私有 1公开, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, INDEX idx_subject_type (subject_id, question_type), INDEX idx_knowledge (knowledge_id), INDEX idx_owner (owner_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里的关键决策是选项存 JSON不拆子表答案存字符串不拆答案表。这样单表就能表达所有题型查询走通用字段索引专门属性在应用层反序列化。有人会担心 JSON 查询慢但实际业务里几乎没有「按某个选项内容搜题」的需求慢不到哪去。2.2 答案和选项的具体存取协议选项用 JSON 数组存储结构是[{key:A,content:柏林},{key:B,content:伦敦},...]。判断题型 options 直接存null填空题和简答题的 options 也置空。渲染的时候前端拿到这个数组按顺序渲染成单选框或复选框逻辑高度统一。答案字段的格式按题型约定单选题存A多选题存ABD判断题存T或F填空题存[北京,上海]简答题存参考答案纯文本。所有答案最终统一为字符串或 JSON 字符串写入 answer 字段。这里很容易踩的坑是多选题答案一定要排序后存储否则后面「答案命中校验」时ABD和BAD会不一致。我在导入接口里专门做了答案归一化处理按字母排序再落库。2.3 知识点用树形表还是平铺字段知识点我单独建了一张树形表knowledge(id, name, parent_id)科目subject作为一级节点挂在树上。题目只挂一个叶子知识点knowledge_id不搞多对多关联。这个决策吃了不少教训。最开始我设计题目和知识点是多对多一道题可以同时标记「第一章」和「函数与极限」两个标签看起来灵活但组卷时问题就来了按第一章抽 10 题、按函数与极限抽 10 题很容易把同一道题抽进两个分组导致一张卷子里出现重复题。后来改成「一题只挂一个最细粒度知识点」组卷的统计口径就干净了。如果确实需要多标签可以在搜索时用冗余标签字段辅助但核心归属关系必须唯一。3. 组卷逻辑手工选和按规则抽两条路都要落库3.1 手工组卷试卷题目关联表的三件套手工组卷是老师最常用的方式——左侧题目列表右侧试卷面板选中一道拖过去这道题就进了试卷。这个功能涉及三张表试卷主表paper、题目表question、关联表paper_question。关联表是核心结构如下CREATE TABLE paper_question ( id BIGINT AUTO_INCREMENT PRIMARY KEY, paper_id BIGINT NOT NULL, question_id BIGINT NOT NULL, score DECIMAL(5,1) NULL COMMENT 该题在此卷中的分值, sort_order INT NOT NULL COMMENT 排序, created_at DATETIME NOT NULL, UNIQUE KEY uk_paper_question (paper_id, question_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;为什么 score 一定要存在关联表而不是去题目表统一取值因为同一道题在不同试卷里分值可能不同A 卷里是 3 分B 卷里可能变成 5 分。初始化时可以从题目表带出一个默认分值但老师编辑试卷时随时会改。手工组卷最容易被忽视的是排序。老师的习惯是「多选题放前面、填空题放后面」需要随时拖动调整顺序。我的做法是 sort_order 用整数且步长留 10调整时改增量比如第一题 10、第二题 20插入时取中间值 15避免整表重排。题目多了也不怕这个方案足以支撑几百题的卷子。3.2 规则抽题按知识点、难度、题型三个维度取交集规则抽题才是这个系统真正的「智力担当」。需求一句话指定题型、指定知识点范围、指定难度配比系统自动抽出一份符合要求的试卷。规则我用 JSON 表示存储结构是paper.rule字段。一个典型的规则长这样{ sections: [ { questionType: 1, count: 10, score: 3, knowledgeIds: [1, 2, 3], difficulty: {1: 3, 2: 4, 3: 3} }, { questionType: 2, count: 5, score: 4, knowledgeIds: [1, 2], difficulty: {2: 3, 3: 2} } ] }实现思路是按「题型分区 知识点过滤 难度配额」三步走核心代码示意public ListQuestion pickQuestions(PaperRule rule) { ListQuestion result new ArrayList(); SetLong seen new HashSet(); for (SectionRule section : rule.getSections()) { LambdaQueryWrapperQuestion wrapper Wrappers.lambdaQuery(Question.class) .eq(Question::getQuestionType, section.getType()) .in(Question::getKnowledgeId, section.getKnowledgeIds()) .eq(Question::getDeleted, 0); ListQuestion candidates questionMapper.selectList(wrapper); MapInteger, ListQuestion byDifficulty candidates.stream() .collect(Collectors.groupingBy(Question::getDifficulty)); for (Map.EntryInteger, Integer entry : section.getDifficulty().entrySet()) { ListQuestion pool byDifficulty.getOrDefault(entry.getKey(), Collections.emptyList()); Collections.shuffle(pool); int need entry.getValue(); for (Question q : pool) { if (need 0) break; if (seen.add(q.getId())) { result.add(q); need--; } } // 配额不足时记录警告由上层决定是否补齐 } } return result; }这段代码对应了三条设计原则。一是先按题型和知识点过滤缩小候选集合二是按难度分组后 shuffle保证随机性三是在最外层用seen集合做全局去重防止同一道题被抽两次。我一开始没加seen结果出现一道题在卷一和卷二里同时出现的尴尬场景加完之后彻底解决。还有个细节是配额不足的处理。实际题库里「难」的题往往最少如果某难度题量不足直接给老师抛异常不友好。我的做法是抽完题后统计实际配比和规则对比不足的部分从相邻难度池里补齐并在响应里返回一条「难度分布与设定略有偏差」的提示。老师可以接受因为现实就是题库不完美系统要做的是在约束里找最优解。4. 批量导入让老师手上现成的 Word 题进得来4.1 Excel 模板是最小可行方案做这个系统之前我天真地以为 Word 导入是首选后来发现 Excel 模板才是真正让老师「愿意配合」的方案。原因很简单让老师按照固定模板整理题目比让程序去解析千奇百怪的 Word 排版要可靠得多。从成功率和开发成本两个维度看Excel 模板都是性价比之王。我的 Excel 模板列是这样设计的第一行是表头从第二行开始填数据题型题干选项A选项B选项C选项D正确答案解析难度知识点单选中国的首都是北京上海广州深圳A首都为北京2地理常识多选下列属于水果的是苹果土豆香蕉白菜ABD土豆属于蔬菜3生活常识导入用 EasyExcel 流式读取监听器里逐行校验遇到错误不中断收集到ListString里导入结束后把「第几行、哪个字段、什么问题」批量返回给老师。比如「第 38 行题型参数必须是单选、多选、判断、填空、简答之一」「第 42 行知识点『高等数学』不存在请用系统内的标准名称」。一次性把 2000 行里的 30 个问题全部列出来老师改起来效率高得多。4.2 解析 Word 的取舍图片和公式别硬啃Word 导入我做了但只做「最小可用版」。用 POI 解析 docx按段落遍历靠正则识别题号和选项。题干识别用^第?\s*(\d)\s*[.、)]选项识别用^[A-H][.、)]段落归类到最近的题号下。Word 里的图片和公式是最大的坑。我的妥协方案是图片抽取出来存成独立文件正文中用img src/upload/2025/...占位公式如果是 Word 自带公式编辑器生成的 OMML 对象第一版不转 LaTeX直接整段转成图片插入富文本。这样虽然公式无法编辑但至少渲染出来是完整的老师看着不违和。真正要避免的是把图片 Base64 编码塞进数据库。我见过有人这么干一张带 20 张图的 Word 转出来单条记录的 content 字段能有几百 KB数据库直接被撑爆。图片必须走文件存储数据库只存 URL 相对路径部署时前端用统一前缀拼接。4.3 导入的稳定性比「智能」更重要导入功能上线后老师反馈最多的问题不是「识别错了」而是「导入到一半失败了前面的白做了」。后来我把导入改成「先校验后落库」两个阶段第一阶段读 Excel 逐行校验格式和引用字段把所有错误收集起来第二阶段如果错误列表为空才真正批量插入数据库。校验通过后还要处理好几个边界题目内容和已有题库重复的问题我加了一个可选「按题干 MD5 去重」的开关知识点名称错误时允许老师在导入结果页直接选择「映射到已有知识点」而不是回去改表导入过程中间有一条格式异常别的正常行仍然要进去不搞全量回滚。稳定性和容错性才是老师真正买单的地方。5. 权限与数据隔离多人协作时最容易被忽视5.1 角色划分和控制粒度题库系统不会只有一个人用。学校里可能是多个老师共用机构里可能是多个学科组共用。如果不做权限隔离A 老师辛辛苦苦建的一套模拟卷被 B 老师改得面目全非这种事故不用多发生一次就没人敢用了。我建了三张权限表sys_user、sys_role、sys_user_role角色按三层划分。管理员拥有全部权限可以管理所有题目和试卷负责维护科目、知识点这些基础数据教师能创建和管理自己的题目、试卷也能查看公共题库学生角色在第一版里只分配了「查看被授权的试卷」的只读权限不设计刷题对错的记录逻辑。接口层面用 Sa-Token 的注解做粗粒度控制比如SaCheckRole(teacher)只能保证角色正确真正麻烦的是数据权限。5.2 「我的题」「公开题」双池设计数据权限上我用了最简单也最稳定的方案每道题记录owner_id和is_public两个字段查询时统一拼条件Long currentUserId StpUtil.getLoginIdAsLong(); LambdaQueryWrapperQuestion wrapper Wrappers.lambdaQuery(Question.class) .eq(Question::getDeleted, 0) .and(w - w.eq(Question::getOwnerId, currentUserId) .or() .eq(Question::getIsPublic, 1));教师端页面明确拆成「我的题库」和「公共题库」两个 tab组卷时默认范围是「我的题目 公开题目」。这样设计有几个好处老师自己准备的小测题可以只自己可见等教研组审核通过后再一键公开公共题库沉淀了全校、全机构的优质资产但任何人都改不了别人的私有题。私有题被老师删除后公共池不受影响逻辑删除保证引用不崩。试卷同样走这套逻辑paper表里有owner_id和is_public。公开的试卷所有老师可见但只有创建人或管理员能编辑。学生看试卷通过单独的分享码或链接不走这套复杂的权限链。6. 实测阶段处理的几个隐蔽问题6.1 ORDER BY RAND() 在题目量上来后的退化规则抽题第一版我用的是 SQL 直接ORDER BY RAND() LIMIT n题库几百道题时毫无压力但导入到 8000 多道题后接口响应明显变慢。原因很简单ORDER BY RAND()会对全表每一行生成随机数再排序数据量一大就退化成了全表扫描加排序。优化方案改成两段式先用索引把符合条件的 id 列表查出来对 id 列表做ORDER BY RAND()取 n 个再按 id IN 去查完整记录。因为 id 主键的体积小很多随机排序的开销大幅下降。实测 8000 题场景下接口从 1.8 秒降到了 200 毫秒以内效果立竿见影。真正到了几十万题这个方案仍然不够到时候再考虑把候选集按知识点拆成多个小集合分别随机这是后话。6.2 富文本 XSS 和公式渲染题目内容是富文本老师从 Word 粘贴过来时会带入大量内联样式和奇怪的标签更危险的是可能携带script脚本。如果用v-html直接渲染任何一个老师粘贴了一段带脚本的内容整个教研组的浏览器都会遭殃。即使不是恶意攻击Word 粘贴的o:p、style标签也足够让前端样式乱成一团。我的处理分两层后端入库时用 Jsoup 做白名单过滤只保留p、span、img、table、ol、ul、li、strong、em、sub、sup等标签其他全部清掉前端渲染前再用 DOMPurify 过一道防线。公式方面编辑器里输入的内容如果是 LaTeX 文本渲染时用 KaTeX 解析但从 Word 导入的公式以图片形式存在前端直接显示图片。这个方案虽然不算优雅但胜在稳定。6.3 删除题目与试卷引用的冲突处理物理删除是最容易踩的坑。题目一旦被某张试卷引用物理删除会导致试卷打开时题目缺失甚至组好的卷子直接报空指针。我的方案是「逻辑删除 引用校验」双保险question.deleted改成 1 表示删除删除前查询paper_question是否存在关联记录如果存在就提示「该题已被 3 张试卷引用无法删除可改为私有状态」。试卷本身的删除类似。试卷被学生作答记录引用后不能物理删除只能标记为归档。这个逻辑虽然简单但能避免最尴尬的线上事故。我见过一个系统因为删除没做引用校验老师辛辛苦苦组好的期末考试卷某道题被管理员顺手删了考试当天试卷缺了一整道题。做这个系统的最大体会是题库管理系统的难点从来不在某个炫酷的算法而在把题目这种不规整的数据用一套规整的模型存好再把组卷、导入、权限这些日常操作做顺。如果你也正在做类似项目我建议先拿自己手头的一份 Word 试卷从导入到组卷再到导出完整走一遍这个流程哪里卡住哪里就是系统真正需要重点打磨的地方。本文还有配套的精品资源点击获取 从零构建可用的题库管理系统：建模、组卷与导入实战
简介试题库管理系统是一份基于Qt框架与SQL数据库的课程设计完整资源面向高校计算机专业学生及需要完成数据库课程设计的开发者可帮助解决题库管理、随机组卷、成绩统计与数据持久化等典型问题。资源共47个文件压缩包约1.29MB源码部分包含5个cpp、7个h、3个ui及pro工程文件可直接编译运行数据库方面带有1个sql脚本便于建库建表和数据初始化另有5个qss样式表、12个png界面截图以及3份docx与1份doc文档涵盖任务书、课程设计报告、数据流图与模块实现说明可清晰还原从需求分析、概念结构设计到逻辑结构设计的完整过程。目前已有1706人学习下载适合作课程设计选题参考、答辩材料范本也能用于练习Qt与SQL的联动开发。 很多同学把试题库管理系统当普通 CRUD 项目来练手我一开始也是这么干的。结果做完了才发现一个致命问题系统能跑通但没有任何人愿意往里传题。题目录不进去题库就是空的题库是空的组卷、刷题全是空中楼阁。这篇博文把我从零做一个可用的题库管理系统的完整过程写出来重点不是某个框架的 API而是题目怎么建模、组卷规则怎么落库、Word 里的存量题怎么批量进来以及多人共用一套系统时权限怎么隔离。适合正在做毕设、课程设计或者想给学校、机构搭一套内部题库工具的朋友参考。1. 先定义清楚边界题库系统要解决的是「攒题难、出卷乱」1.1 我划掉的功能在线考试和自动阅卷很多人拿到这个需求的第一反应是做完整在线考试平台定时下发、防切屏、自动判分、成绩排名一套全上。我第一版把这些全部划掉了只保留四件事题目管理、组卷、批量导入导出、权限隔离。这里有个很现实的理由题库系统的核心价值在于把题目这种数据资产沉淀下来而出题、审题、整理格式才是最耗人力的环节。老师们手里拿着一堆 Word 试卷想要的是「能把这些题快速存进去然后按知识点抽出来组一张新卷子」至于学生怎么在线考那是消费题库的另一种方式等题量攒起来再做完全来得及。我把第一版功能边界整理成了一张表建议你也照这个思路控制范围模块第一版做不做判断理由题目增删改查做基础中的基础手工组卷做老师最常见的使用路径按知识点/难度规则抽题做区别于「大号 Excel」的核心功能Excel 批量导入模板做决定存量题能不能进得来Word 试卷自动解析做最小可用版能解析纯文本和图片不追求完美在线考试不做放到二期先解决数据从哪来自动判分不做题型复杂判分规则容易失控成绩统计报表不做没有考试数据支撑做了也是空壳明确边界之后整个系统的数据模型、接口设计都会清晰很多自己写代码不会被「万一以后要加 XX 功能」卡住。1.2 技术选型为什么是 Spring Boot Vue而不是「全家桶」技术栈我选了 Spring Boot 2.7 MyBatis-Plus MySQL 8前端 Vue 3 Element Plus权限用 Sa-Token。这套组合在中小型管理系统里属于最稳妥的方案资料全、能搜到的坑多、一个人也维护得住。不用 Redis、不用 Elasticsearch、不用微服务。题目量到几十万之前MySQL 的普通索引加几个优化手段完全够用真要上全文检索等系统活过一年再引入也不迟。Redis 在这里最多用来做缓存热点题属于优化而非必选项。选型这件事少即是多。Spring Boot Vue 的好处是万一项目要交接给下一个同学对方大概率也用过这套技术栈学习成本低。2. 题目表设计多态题型靠一个 JSON 字段撑住了2.1 一张表还是多张表我选一张主表加 JSON 的原因题目这玩意儿最麻烦的地方是它的「长相」差异太大。单选题有选项 ABCD判断题只有对和错填空题有几个空简答题没有标准选项只有参考答案。如果按教科书做法拆题表、选项表、答案表后面每次查询都要 JOIN 四五张表组卷时组装对象更是噩梦。我用了一张主表把题型的公共字段抽出来把「题型特有属性」塞进 JSON 字段。核心表结构长这样CREATE TABLE question ( id BIGINT AUTO_INCREMENT PRIMARY KEY, question_type TINYINT NOT NULL COMMENT 1单选 2多选 3判断 4填空 5简答, content MEDIUMTEXT NOT NULL COMMENT 题干富文本HTML, options JSON NULL COMMENT 选项JSON如[{key:A,content:...}], answer VARCHAR(512) NOT NULL COMMENT 答案按题型约定序列化, analysis MEDIUMTEXT NULL COMMENT 答案解析, difficulty TINYINT NOT NULL DEFAULT 3 COMMENT 难度1-5, subject_id BIGINT NOT NULL COMMENT 所属科目, knowledge_id BIGINT NULL COMMENT 所属知识点, owner_id BIGINT NOT NULL COMMENT 创建人, is_public TINYINT NOT NULL DEFAULT 0 COMMENT 0私有 1公开, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, INDEX idx_subject_type (subject_id, question_type), INDEX idx_knowledge (knowledge_id), INDEX idx_owner (owner_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里的关键决策是选项存 JSON不拆子表答案存字符串不拆答案表。这样单表就能表达所有题型查询走通用字段索引专门属性在应用层反序列化。有人会担心 JSON 查询慢但实际业务里几乎没有「按某个选项内容搜题」的需求慢不到哪去。2.2 答案和选项的具体存取协议选项用 JSON 数组存储结构是[{key:A,content:柏林},{key:B,content:伦敦},...]。判断题型 options 直接存null填空题和简答题的 options 也置空。渲染的时候前端拿到这个数组按顺序渲染成单选框或复选框逻辑高度统一。答案字段的格式按题型约定单选题存A多选题存ABD判断题存T或F填空题存[北京,上海]简答题存参考答案纯文本。所有答案最终统一为字符串或 JSON 字符串写入 answer 字段。这里很容易踩的坑是多选题答案一定要排序后存储否则后面「答案命中校验」时ABD和BAD会不一致。我在导入接口里专门做了答案归一化处理按字母排序再落库。2.3 知识点用树形表还是平铺字段知识点我单独建了一张树形表knowledge(id, name, parent_id)科目subject作为一级节点挂在树上。题目只挂一个叶子知识点knowledge_id不搞多对多关联。这个决策吃了不少教训。最开始我设计题目和知识点是多对多一道题可以同时标记「第一章」和「函数与极限」两个标签看起来灵活但组卷时问题就来了按第一章抽 10 题、按函数与极限抽 10 题很容易把同一道题抽进两个分组导致一张卷子里出现重复题。后来改成「一题只挂一个最细粒度知识点」组卷的统计口径就干净了。如果确实需要多标签可以在搜索时用冗余标签字段辅助但核心归属关系必须唯一。3. 组卷逻辑手工选和按规则抽两条路都要落库3.1 手工组卷试卷题目关联表的三件套手工组卷是老师最常用的方式——左侧题目列表右侧试卷面板选中一道拖过去这道题就进了试卷。这个功能涉及三张表试卷主表paper、题目表question、关联表paper_question。关联表是核心结构如下CREATE TABLE paper_question ( id BIGINT AUTO_INCREMENT PRIMARY KEY, paper_id BIGINT NOT NULL, question_id BIGINT NOT NULL, score DECIMAL(5,1) NULL COMMENT 该题在此卷中的分值, sort_order INT NOT NULL COMMENT 排序, created_at DATETIME NOT NULL, UNIQUE KEY uk_paper_question (paper_id, question_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;为什么 score 一定要存在关联表而不是去题目表统一取值因为同一道题在不同试卷里分值可能不同A 卷里是 3 分B 卷里可能变成 5 分。初始化时可以从题目表带出一个默认分值但老师编辑试卷时随时会改。手工组卷最容易被忽视的是排序。老师的习惯是「多选题放前面、填空题放后面」需要随时拖动调整顺序。我的做法是 sort_order 用整数且步长留 10调整时改增量比如第一题 10、第二题 20插入时取中间值 15避免整表重排。题目多了也不怕这个方案足以支撑几百题的卷子。3.2 规则抽题按知识点、难度、题型三个维度取交集规则抽题才是这个系统真正的「智力担当」。需求一句话指定题型、指定知识点范围、指定难度配比系统自动抽出一份符合要求的试卷。规则我用 JSON 表示存储结构是paper.rule字段。一个典型的规则长这样{ sections: [ { questionType: 1, count: 10, score: 3, knowledgeIds: [1, 2, 3], difficulty: {1: 3, 2: 4, 3: 3} }, { questionType: 2, count: 5, score: 4, knowledgeIds: [1, 2], difficulty: {2: 3, 3: 2} } ] }实现思路是按「题型分区 知识点过滤 难度配额」三步走核心代码示意public ListQuestion pickQuestions(PaperRule rule) { ListQuestion result new ArrayList(); SetLong seen new HashSet(); for (SectionRule section : rule.getSections()) { LambdaQueryWrapperQuestion wrapper Wrappers.lambdaQuery(Question.class) .eq(Question::getQuestionType, section.getType()) .in(Question::getKnowledgeId, section.getKnowledgeIds()) .eq(Question::getDeleted, 0); ListQuestion candidates questionMapper.selectList(wrapper); MapInteger, ListQuestion byDifficulty candidates.stream() .collect(Collectors.groupingBy(Question::getDifficulty)); for (Map.EntryInteger, Integer entry : section.getDifficulty().entrySet()) { ListQuestion pool byDifficulty.getOrDefault(entry.getKey(), Collections.emptyList()); Collections.shuffle(pool); int need entry.getValue(); for (Question q : pool) { if (need 0) break; if (seen.add(q.getId())) { result.add(q); need--; } } // 配额不足时记录警告由上层决定是否补齐 } } return result; }这段代码对应了三条设计原则。一是先按题型和知识点过滤缩小候选集合二是按难度分组后 shuffle保证随机性三是在最外层用seen集合做全局去重防止同一道题被抽两次。我一开始没加seen结果出现一道题在卷一和卷二里同时出现的尴尬场景加完之后彻底解决。还有个细节是配额不足的处理。实际题库里「难」的题往往最少如果某难度题量不足直接给老师抛异常不友好。我的做法是抽完题后统计实际配比和规则对比不足的部分从相邻难度池里补齐并在响应里返回一条「难度分布与设定略有偏差」的提示。老师可以接受因为现实就是题库不完美系统要做的是在约束里找最优解。4. 批量导入让老师手上现成的 Word 题进得来4.1 Excel 模板是最小可行方案做这个系统之前我天真地以为 Word 导入是首选后来发现 Excel 模板才是真正让老师「愿意配合」的方案。原因很简单让老师按照固定模板整理题目比让程序去解析千奇百怪的 Word 排版要可靠得多。从成功率和开发成本两个维度看Excel 模板都是性价比之王。我的 Excel 模板列是这样设计的第一行是表头从第二行开始填数据题型题干选项A选项B选项C选项D正确答案解析难度知识点单选中国的首都是北京上海广州深圳A首都为北京2地理常识多选下列属于水果的是苹果土豆香蕉白菜ABD土豆属于蔬菜3生活常识导入用 EasyExcel 流式读取监听器里逐行校验遇到错误不中断收集到ListString里导入结束后把「第几行、哪个字段、什么问题」批量返回给老师。比如「第 38 行题型参数必须是单选、多选、判断、填空、简答之一」「第 42 行知识点『高等数学』不存在请用系统内的标准名称」。一次性把 2000 行里的 30 个问题全部列出来老师改起来效率高得多。4.2 解析 Word 的取舍图片和公式别硬啃Word 导入我做了但只做「最小可用版」。用 POI 解析 docx按段落遍历靠正则识别题号和选项。题干识别用^第?\s*(\d)\s*[.、)]选项识别用^[A-H][.、)]段落归类到最近的题号下。Word 里的图片和公式是最大的坑。我的妥协方案是图片抽取出来存成独立文件正文中用img src/upload/2025/...占位公式如果是 Word 自带公式编辑器生成的 OMML 对象第一版不转 LaTeX直接整段转成图片插入富文本。这样虽然公式无法编辑但至少渲染出来是完整的老师看着不违和。真正要避免的是把图片 Base64 编码塞进数据库。我见过有人这么干一张带 20 张图的 Word 转出来单条记录的 content 字段能有几百 KB数据库直接被撑爆。图片必须走文件存储数据库只存 URL 相对路径部署时前端用统一前缀拼接。4.3 导入的稳定性比「智能」更重要导入功能上线后老师反馈最多的问题不是「识别错了」而是「导入到一半失败了前面的白做了」。后来我把导入改成「先校验后落库」两个阶段第一阶段读 Excel 逐行校验格式和引用字段把所有错误收集起来第二阶段如果错误列表为空才真正批量插入数据库。校验通过后还要处理好几个边界题目内容和已有题库重复的问题我加了一个可选「按题干 MD5 去重」的开关知识点名称错误时允许老师在导入结果页直接选择「映射到已有知识点」而不是回去改表导入过程中间有一条格式异常别的正常行仍然要进去不搞全量回滚。稳定性和容错性才是老师真正买单的地方。5. 权限与数据隔离多人协作时最容易被忽视5.1 角色划分和控制粒度题库系统不会只有一个人用。学校里可能是多个老师共用机构里可能是多个学科组共用。如果不做权限隔离A 老师辛辛苦苦建的一套模拟卷被 B 老师改得面目全非这种事故不用多发生一次就没人敢用了。我建了三张权限表sys_user、sys_role、sys_user_role角色按三层划分。管理员拥有全部权限可以管理所有题目和试卷负责维护科目、知识点这些基础数据教师能创建和管理自己的题目、试卷也能查看公共题库学生角色在第一版里只分配了「查看被授权的试卷」的只读权限不设计刷题对错的记录逻辑。接口层面用 Sa-Token 的注解做粗粒度控制比如SaCheckRole(teacher)只能保证角色正确真正麻烦的是数据权限。5.2 「我的题」「公开题」双池设计数据权限上我用了最简单也最稳定的方案每道题记录owner_id和is_public两个字段查询时统一拼条件Long currentUserId StpUtil.getLoginIdAsLong(); LambdaQueryWrapperQuestion wrapper Wrappers.lambdaQuery(Question.class) .eq(Question::getDeleted, 0) .and(w - w.eq(Question::getOwnerId, currentUserId) .or() .eq(Question::getIsPublic, 1));教师端页面明确拆成「我的题库」和「公共题库」两个 tab组卷时默认范围是「我的题目 公开题目」。这样设计有几个好处老师自己准备的小测题可以只自己可见等教研组审核通过后再一键公开公共题库沉淀了全校、全机构的优质资产但任何人都改不了别人的私有题。私有题被老师删除后公共池不受影响逻辑删除保证引用不崩。试卷同样走这套逻辑paper表里有owner_id和is_public。公开的试卷所有老师可见但只有创建人或管理员能编辑。学生看试卷通过单独的分享码或链接不走这套复杂的权限链。6. 实测阶段处理的几个隐蔽问题6.1 ORDER BY RAND() 在题目量上来后的退化规则抽题第一版我用的是 SQL 直接ORDER BY RAND() LIMIT n题库几百道题时毫无压力但导入到 8000 多道题后接口响应明显变慢。原因很简单ORDER BY RAND()会对全表每一行生成随机数再排序数据量一大就退化成了全表扫描加排序。优化方案改成两段式先用索引把符合条件的 id 列表查出来对 id 列表做ORDER BY RAND()取 n 个再按 id IN 去查完整记录。因为 id 主键的体积小很多随机排序的开销大幅下降。实测 8000 题场景下接口从 1.8 秒降到了 200 毫秒以内效果立竿见影。真正到了几十万题这个方案仍然不够到时候再考虑把候选集按知识点拆成多个小集合分别随机这是后话。6.2 富文本 XSS 和公式渲染题目内容是富文本老师从 Word 粘贴过来时会带入大量内联样式和奇怪的标签更危险的是可能携带script脚本。如果用v-html直接渲染任何一个老师粘贴了一段带脚本的内容整个教研组的浏览器都会遭殃。即使不是恶意攻击Word 粘贴的o:p、style标签也足够让前端样式乱成一团。我的处理分两层后端入库时用 Jsoup 做白名单过滤只保留p、span、img、table、ol、ul、li、strong、em、sub、sup等标签其他全部清掉前端渲染前再用 DOMPurify 过一道防线。公式方面编辑器里输入的内容如果是 LaTeX 文本渲染时用 KaTeX 解析但从 Word 导入的公式以图片形式存在前端直接显示图片。这个方案虽然不算优雅但胜在稳定。6.3 删除题目与试卷引用的冲突处理物理删除是最容易踩的坑。题目一旦被某张试卷引用物理删除会导致试卷打开时题目缺失甚至组好的卷子直接报空指针。我的方案是「逻辑删除 引用校验」双保险question.deleted改成 1 表示删除删除前查询paper_question是否存在关联记录如果存在就提示「该题已被 3 张试卷引用无法删除可改为私有状态」。试卷本身的删除类似。试卷被学生作答记录引用后不能物理删除只能标记为归档。这个逻辑虽然简单但能避免最尴尬的线上事故。我见过一个系统因为删除没做引用校验老师辛辛苦苦组好的期末考试卷某道题被管理员顺手删了考试当天试卷缺了一整道题。做这个系统的最大体会是题库管理系统的难点从来不在某个炫酷的算法而在把题目这种不规整的数据用一套规整的模型存好再把组卷、导入、权限这些日常操作做顺。如果你也正在做类似项目我建议先拿自己手头的一份 Word 试卷从导入到组卷再到导出完整走一遍这个流程哪里卡住哪里就是系统真正需要重点打磨的地方。本文还有配套的精品资源点击获取