选这个题目之前我其实纠结过很久。毕业设计列表里一眼扫过去SpringBoot、Vue、前后端分离、自动组卷这些关键词太常见也太容易撞车真正让我停下来的是“教考分离”四个字。很多同学做题库系统做完就是一个题目增删改查加一套考试流程功能是完整了但你要在答辩台上说清楚“它到底解决了什么痛点”就很容易被问住。“教考分离”恰好给了这个系统一个明确的问题域教学和命题分离题库共建共享考试自动组卷阅卷评分可追溯。这篇文章我会完整复盘整个系统的设计与实现过程从需求拆解、技术选型、数据库设计、自动组卷算法到在线考试和权限控制最后是实测踩坑记录给正在做类似毕设选题的同学一个能直接参考的思路。这套系统适合谁来参考如果你是计算机科学与技术、软件工程相关专业准备用SpringBoot和Vue做毕业设计或者课程设计想做得有深度一点都可以拿这篇文章当骨架。我会尽量把“为什么这样设计”讲明白而不是只给一堆代码片段。毕竟毕设答辩老师问得最多的不是“你写了多少行代码”而是“你这个模块为什么这么设计有没有考虑过边界情况”。1. 为什么选这个题目教考分离真正的痛点1.1 传统考试模式的问题在哪先别急着谈技术我们来想一个很简单的场景。一门课程有三个教学班三个老师分别教到了期末各出各的卷子。有人出得很简单有人出得很偏学生考试成绩出来之后根本没法横向比较更别说评估教学效果了。这就是“教考合一”的典型问题教的人包办命题主观性太强题库资源也不共享。教考分离的核心逻辑是让“教”和“考”尽量解耦课程组共建一套题库考试时从题库中按规则自动抽题组卷而不是某位任课老师一个人拍脑袋出题。这个场景放到系统设计里就引出了一连串明确的需求。题库要按课程隔离题目要有题型、难度、知识点等标签组卷不能只是随机选几道题要满足分数分布、难度比例、知识点覆盖等约束考试过程要可控交卷要安全可靠考完还要支持主观题人工阅卷和成绩统计分析。这些需求一条条列出来系统的边界就清楚了。1.2 教考分离平台的功能地图基于这个痛点我最终把系统拆成了五个核心模块。第一个是题库管理包含单选、多选、判断、填空、简答等题型每道题可以设置知识点、难度等级和分值第二个是自动组卷支持快速组卷和按模板组卷后者可以设置题型数量、难度比例和知识点权重第三个是考试管理包含创建考试、发布考试、学生进入考试、倒计时控制、交卷和防重复提交第四个是成绩管理自动客观题判分、主观题人工评阅、成绩导出第五个是系统管理负责用户、角色、课程和权限。这五个模块之间的关系是一条完整链路课程建立题库题库支撑组卷组卷生成试卷试卷关联到考试考试产生答题记录答题记录汇成成绩。想明白这条链路数据库的表结构其实就已经在脑子里了。2. 技术选型和架构设计为什么是SpringBoot加Vue2.1 这套组合背后的现实考量现在很多同学一上来就问“老师我能不能用SpringBoot加FreeMarker模板不搞前后端分离”说实话如果只是想做出能跑的功能单体JSP确实更快页面和接口放一起也省事。但毕设选型不能只看开发速度还要看展示效果、后续扩展和找工作面试时的通用性。SpringBoot加Vue的前后端分离方案好处在于前端和后端可以独立开发、独立部署接口层天然标准化做出来的项目拆开来看也更像企业级应用。技术栈具体是后端Spring Boot 2.7.14Spring Security加JWT做认证鉴权MyBatis-Plus做持久层MySQL 8.0存业务数据Redis缓存热点数据和分布式锁前端Vue 3.2加Vite构建Element Plus做UI组件Axios处理请求Pinia管理全局状态Vue Router 4管理路由跳转。这套组合的社区资料非常多踩坑时随便搜都能找到答案对毕设来说是性价比很高的选择。2.2 后端分层与前端结构怎么搭后端我没有搞花哨的微服务架构单应用多模块就够用。Controller层只做参数接收和响应封装Service层写业务逻辑Mapper层通过MyBatis-Plus操作数据库。为了防止Controller里堆大量判断我在Service层做了比较严格的职责划分题库TopicService只处理题目相关逻辑组卷PaperService只处理试卷生成考试ExamService负责考试流程和交卷事务。类名不需要多炫职责清晰最重要。前端目录按页面和功能拆API层单独建一个目录所有接口调用统一走Axios实例封装Views目录下按角色或业务分文件夹比如teacher目录放课程管理、题库管理、组卷页面student目录放考试列表和在线答题页Router里配置路由守卫登录状态和角色信息写在Pinia中。前端不是简单的html加js散写而是工程化组织导师检查文件结构时也好解释。2.3 前后端数据交互约定前后端一定要提前定好接口规范不然后期联调会非常痛苦。我用的统一响应结构是Result对象包含code、message、data三个字段code为200表示成功401表示未登录或Token过期500表示服务器异常。所有分页接口统一返回PageResult里面是total、records、current、size四个字段。前端Axios拦截器统一处理code遇到401就清除本地登录信息并跳转到登录页。这个约定写下来只花十分钟但整个项目联调周期能省一半时间。接口路径也建议按模块前置比如/api/question开头的都是题库模块/api/paper开头的是组卷模块/api/exam开头的是考试模块方便拆分拦截策略。比如学生角色能访问/api/question下面的题目列表吗不能。但为了查题方便学生端可能需要按条件查看题目。这个矛盾我在权限模块会详细说这里先埋个伏笔。3. 题库与试卷的数据库设计从表结构看数据流转3.1 核心数据表有哪些数据库设计是整个系统最值得花时间的地方表设计不好后面写自动组卷会疯狂写判断逻辑来补漏洞。我最终设计了12张核心表按业务线可以分成四组。用户课程组有sys_user、sys_role、sys_user_role、tb_course、tb_course_user题库组有tb_question、tb_question_option、tb_knowledge_point、tb_course_knowledge_point试卷组有tb_paper、tb_paper_question、tb_paper_rule考试组有tb_exam、tb_exam_paper、tb_exam_record、tb_answer_detail。这里我把试卷组拆成了三张表。tb_paper存试卷基本信息tb_paper_question是试卷和题目的关联表还冗余了题目快照和分值tb_paper_rule存组卷规则。为什么题目快照要冗余一份因为题库里的题目维护者是可以修改的如果考试中途或考完之后题干被改了历史试卷内容就变了学生答题记录对不上。快照字段在生成试卷的那一刻把题目的题干、选项、答案、解析、分值都复制一份存进tb_paper_question后续题库怎么改都不影响已生成试卷的稳定。3.2 题目表字段详解tb_question这张表我单独拎出来讲因为它是组卷算法的重要数据来源。字段包括id、course_id、type题型、content、analysis、difficulty难度等级1-5或者1-3也行、score、创建人、创建时间等。难度建议用数字而不用文字因为自动组卷时要用数字计算枚举值映射方便排序筛选。题目和知识点是多对多关系所以单独建了关联表不能把知识点ID直接塞在题目表里。选择题的选项不直接拼接在题干的content字段里而是放在单独的tb_question_option表每条选项记录含有option_labelA/B/C/D、option_content和is_answer。这样做的原因是系统支持多选题和不定项选择答案可能是多个选项另外学生考试时要把选项顺序打乱单独存才方便随机排序后和答案比对。判分逻辑也比较清晰用选项ID集合比对而不是字符串包含判断避免错判。3.3 试卷生成后的快照流转生成试卷时System.out.println这种调试肯定不行正确定位方法是加日志。自动组卷服务里我把约束参数和最终选中的题目ID列表都打成JSON日志出现长时间查不到题目的时候把参数拿出来手动执行SQL很快就能看出来是知识点名称对不上还是难度分布要求太苛刻。数据库还有一张excel导入模板表结构这里我就不再展开了。4. 自动组卷核心实现随机抽题加上约束校验4.1 组卷需求拆解自动组卷看起来唬人本质是“在满足多约束条件的前提下从题库中选出一批题目的组合优化问题”。举个例子我要出一张满分为100分的试卷要求单选题20道每道2分多选题10道每道3分判断题10道每道2分简答题2道每道10分并且难度构成是易、中、难的比例3:5:2知识点覆盖至少5章同一知识点下的题目不能超过总题量的30%。这些约束如果全堆在一个方法里判断代码会非常难维护。我的做法是先定义组卷规则对象把题型数量、单题分值、难度比例、知识点权重都封装在里面。组卷流程分三步第一步按题型和课程从题库中查出所有候选题目第二步按知识点权重对候选题目分桶第三步在每一个桶里按剩余名额和难度要求随机抽题。抽完所有题型后校验总分数如果总分不等于设定值自动调整最后一类题型的单题分值或补充题目。4.2 随机抽题加回退的代码思路核心理念是“不强求一次完美先随机抽再重复校验”。我用下面的简化逻辑实现public ListLong generatePaper(PaperRule rule) { ListLong selectedIds new ArrayList(); int totalScore 0; for (QuestionTypeRule typeRule : rule.getTypeRules()) { ListQuestion candidates questionMapper.selectList( new LambdaQueryWrapperQuestion() .eq(Question::getCourseId, rule.getCourseId()) .eq(Question::getType, typeRule.getType()) .in(Question::getDifficulty, typeRule.getAllowedDifficulties()) .notIn(Question::getId, selectedIds)); if (candidates.size() typeRule.getCount()) { throw new PaperGenerateException(题型 typeRule.getType() 题量不足); } Collections.shuffle(candidates); for (int i 0; i typeRule.getCount(); i) { selectedIds.add(candidates.get(i).getId()); totalScore candidates.get(i).getScore(); } } if (totalScore ! rule.getTotalScore()) { adjustScore(selectedIds, totalScore, rule.getTotalScore()); } return selectedIds; }实际代码肯定比这复杂主要多了一个循环重试机制。第一次随机抽完后如果知识点覆盖不达标会重新洗牌再抽最多重试三次。三次都不满足就把失败的约束条件返回给前端让教师手动调整参数。这么设计比用遗传算法要简单直观得多对毕设来说已经足够有说服力。如果导师追问能不能用遗传算法优化你可以说知道原理但对于几十上百题量的场景随机抽题加回退的成本已经很低遗传算法的收益主要是极端复杂约束后续可以扩展。4.3 防止同一个知识点被抽太多组卷最容易出现的问题不是题量不足而是随机数一抽十道题有六道来自同一个知识点。解决思路是在候选题目分桶阶段给每个知识点设定一个最大可抽数量上限。比如某次考试总共30题按权重分配知识点A最多抽8题知识点B最多抽5题。抽题时每次从当前知识点桶里随机取取完就判断该知识点是否达到上限达到了就跳过这个桶里的剩余题目。这样即使用随机数抽整体分布也会比较均衡。如果要更精细可以在数据库里给每个题目加一个“最近被抽时间”字段组卷时优先选距离上次被抽时间较长的题目这样考试之间的题目重复率低也更好规避泄题风险。这个优化点我在答辩时特意提了老师觉得考虑得很细。5. 在线考试的关键细节倒计时、交卷和防作弊5.1 考试中学生的操作流程学生进入考试后页面会展示试卷所有题目而不是一题一页。这个交互决策我是故意的因为一题一页很容易造成学生心理紧张而且频繁请求接口对服务器压力大。所有题目一次性加载到前端在内存中维护答题状态倒计时独立走一个定时器每30秒向后端汇报一次心跳这样后端能判断学生是否异常退出。倒计时用setInterval实现注意不要随页面刷新重置。我的做法是考试记录表里存一个startTime前端拿到考试总时长后用服务端时间计算剩余时间而不是用本地时间。本地时间修改一下就能多出半小时这个问题必须堵住。前端每次进入考试页面都重新从后端拉一次剩余时间防止页面停留时间过长导致计时偏差。5.2 选项乱序和判分逻辑选择题学生端看到的选项顺序是随机的这个功能听起来小实现时坑不少。如果直接在前端把选项数组打乱学生提交的答案只是“视觉顺序”下的选项编号而后端存的正确答案是原始ABCD判分就会错。我采用的方案是后端加载试卷时返回每个题目的原始选项前端拿到后再用洗牌算法打乱显示顺序但提交答案时提交的是每个选项的唯一ID而不是A/B/C/D。后端判分时比对的是选项ID集合和视觉顺序无关。多选题判分时如果题目要求“少选得一半分错选不得分”后端比较学生提交的选项ID集合和正确答案集合先判断是否为正确答案子集再按比例给分。这个规则在组卷的时候就已经存到tb_paper_question的快照里考试历史数据不会因为后来题目调整而变化。5.3 防止重复交卷和异常刷新交卷接口是考试系统并发风险最高的地方学生手滑双击交卷按钮或者网络超时后重试都可能造成同一份答卷提交两次。如果后端不做幂等处理成绩表会插入两条记录统计分析直接出问题。我用了双重保障第一层是Redis的setIfAbsent以“exam:submit:{examId}:{studentId}”作为key第一次提交才能设置成功第二层是数据库在tb_exam_record表加学生和考试的唯一索引防止极端情况下Redis失效造成重复。学生考试中途退出页面或者刷新前端会弹窗确认如果确认退出则自动交卷。这个功能需要监听beforeunload事件和后端心跳超时判断配合。我的方案是学生每次心跳都刷新服务端的lastHeartbeatTime如果考试时长到或者手动交卷记录状态改为“已交卷”如果长时间没有心跳且未交卷定时任务将状态置为“异常结束”试卷按已作答部分判分。这个兜底逻辑能避免学生在考试中途关电脑后卡住考试名额。6. 权限控制与数据隔离三类角色不能各管各的6.1 基于JWT的角色权限设计系统有管理员、教师、学生三类角色权限边界必须严格。管理员负责用户和课程管理教师负责自己课程下的题库和组卷学生只能看到自己已选课程下的考试并参加考试。权限控制分两层第一层是接口访问权限用Spring Security配置URL规则比如/api/admin/**需要管理员角色/api/teacher/**需要教师角色第二层是数据归属控制教师登录后只能操作course_user表里关联到自己账户的课程数据。数据归属控制是很多毕设容易漏掉的地方。只在前端把“题目管理”菜单藏掉是不够的学生完全可以手动调用接口查题目。我在Service层加了一个当前登录用户上下文ThreadLocal里存着userId和角色每次操作前先校验这条数据的courseId是否属于当前用户。这样即使有人猜到接口地址后端也不会返回数据。这个细节在答辩时非常加分因为真正体现了一个人有数据安全的意识。6.2 菜单和路由的动态渲染前端菜单根据角色动态生成而不是写死一个静态sidebar。管理员看到系统管理菜单教师看到课程管理、题库管理、组卷中心学生看到考试列表、成绩查询。实现方式是登录成功后接口返回菜单列表前端用Vue Router的addRoute动态添加路由。这里有个注意事项刷新页面时Pinia里的菜单数据会丢要再调一次接口重新拉取所以路由守卫里要判断store里有没有菜单数据没有就先拉取再放行。权限和考试流程还有一个交叉点考试中的学生能不能查看题库答案是不能。学生查看题目的接口只开放给考试作答场景通过考试活动ID和试卷ID关联拉取题目时不返回答案字段。阅卷时教师端能看到答案学生端看不到。这种“面向场景开放数据”的设计比简单粗暴地禁止所有学生访问题库更合理。7. 实测阶段的踩坑记录跨域、时区、并发问题7.1 跨域和本地联调的坑前后端分离开发最常用的坑就是跨域。我一开始在后端写了CorsConfig允许所有来源和所有请求头开发环境跑通了。但前后端分别部署到不同域名后又出现跨域问题原因是Nginx没有配置代理前端请求直接打到了后端服务端口。解决方案有两种一种是后端继续开CORS另一种是让Nginx统一反向代理前端只请求同域的/apiNginx再把请求转发到后端服务。我最终采用的是第二种方案生产环境更安全配置也更简洁。7.2 数据库时区导致的时间差第一次部署到服务器后发现数据库里存的时间比北京时间少了8个小时。原因是MySQL连接串里没有指定serverTimezone默认用的是服务器系统时区有时候是UTC。我统一在JDBC连接串里加了serverTimezoneAsia/Shanghai后端Jackson配置也统一了LocalDateTime的格式化模式。所有时间相关的字段都建议存UTC时间或统一存北京时间不要一半依赖数据库默认值一半靠后端代码生成否则统计考试时长时会出现负值这种诡异问题。7.3 交卷并发的小事故系统组织过一次20人同时在线模拟考试结束前1分钟所有人集中交卷结果有两条记录重复插入导致成绩统计异常。排查之后发现是Redis的setIfAbsent在极端情况下返回了true但数据库事务还没提交第二个请求到来时Redis key已被第一个请求占用应该会被拦截才对。后来仔细看日志发现第一个请求事务回滚了但Redis key没有删除导致用户重试时被误判为重复提交。修复方案是把Redis key的删除放到事务提交之后同时数据库唯一索引兜底两个机制加起来覆盖了大部分并发场景。7.4 自动组卷慢的优化题库数据量到了三万条之后单纯用SQL查询候选题目再全量洗牌组卷接口需要两秒多。优化方案是多级过滤先把课程ID、题型、难度这些索引字段过滤出来再在内存中用知识点和最近被抽时间排序最后只在过滤后的候选集里洗牌。再加上查询时只查题目ID和基础字段不查大字段的题干内容等题目确定后再批量查询完整信息。优化后组卷接口压到了一秒以内对毕设演示来说完全够用。8. 从毕设到可落地项目答辩准备和扩展思路8.1 答辩时最值得展开的四个设计点答辩老师通常不会深挖你写了多少页面而会更关注几个关键设计是否站得住。第一个是教考分离的业务闭环从题库到组卷到考试到阅卷再到成绩分析能完整走通第二个是试卷快照机制我解释了为什么题目不能实时引用而要做快照老师点头了第三个是提交幂等和异常考试处理体现了分布式系统的基本素养第四个是权限数据隔离虽然没有华丽的算法但每个接口都有数据归属校验这是企业开发里最基础也最容易被忽视的能力。准备答辩前建议自己先把这几个流程图在纸上画一遍不要只对着PPT念。我当时把数据库ER图打印出来贴在桌上每天看一遍后来老师问任何表之间的关系我都能直接答出来。这套系统的核心不是某个炫技功能而是整个数据链路完整可靠这一点在答辩和写设计文档时都是主线。8.2 还能怎么扩展如果你想在毕设基础上做得更有亮点可以加三个方向。第一个是错题本考试结束后自动把学生答错的题目归类按知识点生成薄弱点分析第二个是成绩分析报表用ECharts展示每个知识点的得分率和分数段分布教师能直观看到教学效果第三个是编程题在线评测如果是计算机课程可以接一个简单的代码沙箱实现编程题的自动判分。这三个方向都不需要重构现有的表结构都是在现有考试记录和答题明细基础上做二次加工扩展成本不高但展示效果提升明显。最后分享一个非常实用的小技巧整个项目用Docker Compose。把MySQL、Redis、后端应用、前端Nginx用几个配置文件打包起来在一台新服务器上只要一条命令就能启动全部环境。这不仅能节省部署时间更重要的是在答辩现场不用慌不用现场配置数据库、改IP点一个脚本就能恢复演示环境。我当时就是因为换了电脑之后环境各种报错才花了一个下午把所有依赖都容器化了后来现场演示一次通过。如果你照着这篇文章的思路去搭这个系统我建议你从数据库设计开始先把表建好、把流程走通再补页面和细节。题库系统最怕的就是建表的时候偷懒后面所有功能都会为这个偷懒买单。