在线考试系统这个题目在毕业设计里属于“常青树”级别的选题。每年都有大量计算机相关专业的学生选它尤其是带“高分”字眼的版本往往意味着功能完整、文档齐全、演示效果好。这套题之所以受欢迎是因为它既有业务逻辑的复杂度又有一眼就能看懂的需求场景评委问起来你也好解释不至于做到一半自己都讲不清楚系统是干嘛的。但你真把一个在线考试系统做完、做好、能过答辩和你在B站跟一个“XX系统实战”视频敲一遍代码完全是两码事。前者需要你搞明白模块边界、权限模型、数据结构、并发控制、异常处理这些真实工程问题后者只是让你照着打一遍。这篇内容我按照一套完整毕业设计的标准把在线考试系统的源码、数据库、Word文档和PPT这条线整体盘一遍重点讲清楚设计思路、核心实现、答辩前你要准备的东西以及最容易踩的那些坑。如果你是刚拿到题目、还没动手或者数据库建了一半觉得不对劲想推翻重来这篇文章能帮你少走不少弯路。1. 内容整体设计与思路拆解先别急着写代码。毕业设计这东西尤其是要拿高分的本质上是一个“工程演示论文表达”的复合产物。你自己会写代码不算本事能让答辩老师快速get到这个系统的亮点、难度和工作量才算本事。1.1 核心需求解析到底要做一个什么样系统一个合格的在线考试系统核心需求拆开就三句话老师能管理题目和试卷学生能在线答题并得到成绩管理员能管人管课程管全局。你仔细看这三句话它对应的是三种完全不同的用户角色每个角色看到的界面、能操作的功能、背后的数据权限都不一样。这就是信息系统中经典的RBAC基于角色的访问控制模型。很多同学做的系统被老师说“像个后台管理页面不像考试系统”原因就在这——只做了增删改查没做角色区分和业务流程闭环。什么是业务流程闭环学生登录后能看到自己的待考列表点进去考试倒计时开始答完交卷系统自动算出客观题分数主观题等老师批阅完给出总分学生能在成绩单里看到历史考试记录和错题分析。这个闭环走完才叫考试系统。如果只是把题目CRUD了一下那叫题库管理系统不叫在线考试系统。从“高分毕业设计”的角度我建议你在满足基本闭环的基础上再加两个有区分度的点一个是随机组卷策略一个是简单的防作弊机制。前者能在论文里写出算法设计后者能在答辩时体现出你对真实应用场景的考量。这两点下文会详细展开。1.2 技术栈选型工具箱里挑什么很多同学纠结用Java还是Python、用SSM还是Spring Boot、要不要加Redis。我直接说结论如果你是Java方向首选Spring Boot MyBatis或MyBatis-Plus MySQL前端用JSP或Thymeleaf即可别强行上前后端分离。为什么要这么选核心逻辑是“稳定可控、文档多、能自圆其说”。Spring Boot的自动配置极大降低了配置工作量你不用像SSM那样写一堆XML配置文件这对时间紧张的大四学生来说是实打实的友好。MyBatis-Plus的逆向生成工具能直接根据数据表生成实体类、Mapper接口和ServiceImpl省掉大量重复代码。MySQL不用多说毕业设计最稳妥的选择。前端不动Vue ElementUI这类前后端分离方案不是因为它不好而是因为答辩环境不确定性太强。你想想答辩现场用的是实验室的老电脑数据库版本、Node环境都可能有问题。单体应用的部署链路是“MySQL 一个Tomcat内嵌 浏览器”前后端分离要多一套Node环境和跨域处理。现场翻车概率更高实在没必要给自己加戏。Python方向的Django也好用管理后台是现成的但Java在后续找工作时项目经验更拿得出手。这个你自己权衡。1.3 谁适合用这套方案这套方案最适配的是以下三类人群第一类是Java基础一般、没独立做过完整项目的同学。照着这个设计的思路走一遍你能把Spring Boot的核心用法、MyBatis操作数据库的方式、Session管理用户状态的机制全部串起来比看网课理解深得多。第二类是时间紧张的同学。比如你三月份才开始动手五月底就要答辩。这套方案的开发工作量完全可以压缩在三到四周内完成前提是你不纠结、不花大把时间抠样式。第三类是想要高分的同学。我后面讲到的随机组卷、防作弊、数据报表这些点任意采纳两三个做成重点特色功能论文就有东西写答辩就有东西吹。至少比“系统支持用户的增删改查”听起来高级两个档次。2. 系统架构与数据库设计数据库是整套系统的地基。我在实际改别人毕业设计的时候发现一个规律凡是数据库设计得一塌糊涂的系统代码怎么写都是别扭的凡是表结构清晰合理的功能实现起来往往很顺畅。所以这一部分我建议你多花时间把表结构设计打磨好再动代码。2.1 角色权限模型三类用户一张用户表常见的在线考试系统角色至少要分三种管理员、教师、学生。有人会把三种角色拆成三张用户表比如admin表、teacher表、student表。我建议不要这样。如果三种角色拆表登录逻辑要写三套用户信息如果要被打通比如一个人既是老师又是管理员就极其痛苦。更好的做法是一张用户表user通过role字段区分角色同时在用户表旁边扩展不同的信息表来存放角色独有的属性。比如表可以这么设计表sys_user用户主表—— id、username、password记得存MD5或BCrypt加盐之后的值、real_name、role1管理员、2教师、3学生、department、status、create_time表stu_info学生扩展表—— id、user_id、student_no学号、grade年级、major专业表teacher_info教师扩展表—— id、user_id、teacher_no工号、title职称这样登录时查sys_user得到角色再去对应的扩展表拿角色信息。权限拦截在拦截器或过滤器中做写一个拦截器判断当前Session中的用户角色是否允许访问某个URL前缀比如/admin/、/teacher/、/student/**很清晰。2.2 题库、试卷、考试、成绩四张核心表的关联逻辑接下来是业务核心表。在线考试系统的核心链路是题库 → 试卷 → 一场考试 → 学生答题 → 成绩。我一般拆成以下几张表表tb_question题库表—— id、course_id所属课程、question_type1单选、2多选、3判断、4简答、question_content、option_a、option_b、option_c、option_d、answer标准答案、score分值、difficulty1易、2中、3难表tb_paper试卷表—— id、paper_name、course_id、total_score、duration考试时长分钟、question_ids试题ID集合、creator_id、create_time表tb_exam考试记录表—— id、paper_id、exam_name、start_time、end_time、status0未开始、1进行中、2已结束、invigilator监考教师表tb_exam_record学生考试记录表—— id、exam_id、student_id、join_time、submit_time、objective_score客观题得分、subjective_score主观题得分、total_score、status0未参加、1考试中、2已交卷这里有个容易搞混的设计点一张试卷可以被多场考试复用。比如老师用A卷周一让1班考周二让2班考这两次是两场不同的考试但试卷是同一套。所以试卷表paper和考试exam要拆开。同理每次考试每个学生的答题情况也要单独记录不能覆盖。学生提交的答案怎么存建议单独建一张答题明细表表tb_answer_detail—— id、exam_record_id、question_id、student_answer学生填写的答案、is_correct判分结果、score_get本题得分这样成绩单页面可以展示“每道题你选的什么、正确答案是什么、你得了多少分”也就是错题回看功能。这对论文里的“教学反馈模块”是很好的素材。2.3 MySQL建库建表实操与常见坑建表和SQL的编写我建议直接在Navicat或MySQL Workbench里操作手动建表完成后导出SQL脚本。这样你拿来放进Word附录和数据库资源里都方便。建库的统一规范是字符集用utf8mb4排序规则用utf8mb4_general_ci。为什么强调utf8mb4而不是utf8因为utf8在MySQL里最多存3个字节的字符而一些生僻字和emoji是4个字节如果你题库里有数学符号或学生姓名里有生僻字utf8可能存不进去报错。utf8mb4是utf8的超集兼容性更好。建表时的几个注意点主键统一用自增idint类型就够用bigint反而占空间。表示状态的字段用tinyint比如0、1、2不要用varchar存“进行中”这种文字查询和判断都不方便。create_time字段用datetime类型统一用数据库的默认值CURRENT_TIMESTAMP。逻辑外键比如exam_record表里的student_id可以不用数据库外键约束但必须在设计文档里写明逻辑关系。物理外键在删除数据时容易造成关联错误项目阶段用逻辑外键能省很多麻烦。密码字段长度至少设置64因为BCrypt加密后的字符串比较长长度不够会直接报错。最后还有一个实用技巧建完表之后把建表SQL脚本导出成一份完整的.sql文件放到项目根目录的sql文件夹下。你和别人展示项目时对方只需要执行这一个SQL文件就能把整个数据库结构建好。这让项目在使用和演示时的专业度提升不少。3. 核心模块实现与关键代码解析数据库设计好了代码实现就是顺着业务链路一步步补全。这一部分我会挑核心模块讲包括登录会话、随机组卷、在线答题和交卷判分。每一块都有值得注意的细节。3.1 登录与会话管理从Cookie到Session再到拦截器先讲登录。用户提交用户名密码后服务端查到sys_user比对密码是否匹配。匹配通过把user对象放进Session。PostMapping(/login) public String login(String username, String password, HttpSession session, Model model) { User user userService.login(username, password); if (user null) { model.addAttribute(error, 用户名或密码错误); return login; } session.setAttribute(loginUser, user); return redirect:/index; }这里面有第一个容易错的点密码不能明文存数据库。哪怕答辩老师不看你的库论文里写“密码以MD5加密存储”也是基本的防泄漏姿态。MD5现在容易被彩虹表碰撞更稳的是用Spring Security自带的BCryptPasswordEncoder。但如果你不想引入整个Spring Security框架也可以只用它的加密工具类自己写一个MD5加盐的工具类也行至少比明文强。登录之后是访问控制。写一个拦截器继承HandlerInterceptor在preHandle方法中判断Session是否存在loginUser不存在就重定向到登录页面。然后注册到Spring Boot的WebMvcConfigurer中并配置拦截路径和不拦截路径。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); User user (User) session.getAttribute(loginUser); if (user null) { response.sendRedirect(/login); return false; } return true; } }这个拦截器能拦下所有未登录访问但你还要再加一道角色控制的处理。比如学生不能访问/teacher/**下的老师功能页面。一种做法是继续写一个RoleInterceptor统一处理判断路径前缀和用户角色是否匹配另一种做法是在每个Controller的方法入口加角色判断。我习惯用过滤器一次性解决访问/admin/**需要role1访问/teacher/**需要role1或2访问/student/**需要role1或3。配置在配置文件里写死清晰好维护。3.2 随机组卷策略与避免重复题目随机组卷是整篇论文里最有技术含量的点之一。它解决的问题是如何从题库中按知识点、难度、题型抽取指定数量的题目组成一套试卷并且保证每次组卷结果不同。最简单的做法是SELECT * FROM tb_question WHERE course_id ? AND question_type 1 ORDER BY RAND() LIMIT 10;这种方式用ORDER BY RAND()随机排序取前N条。在题库规模几千条以内没有问题但数据量大后性能会比较差因为MySQL会对全表做随机排序。不过毕业设计的数据量一般不会太大这个方案简单、能跑、原理也好讲完全够用。如果要写得好一点可以加难度比例参数。比如单选题总10道简单4道、中等4道、困难2道。实现思路就是分别按难度从题库中随机抽取对应数量然后合并成一个题目ID列表。组卷的核心代码逻辑大致是public ListInteger generatePaperQuestions(Long courseId, Integer singleCount, Integer singleEasyCount) { ListInteger result new ArrayList(); // 抽取简单题 singleEasyCount 道 ListQuestion easyList questionMapper.selectRandomByTypeAndDifficulty( courseId, 1, 1, singleEasyCount); // 抽取中等题 (singleCount - singleEasyCount - hardCount) 道 ListQuestion mediumList questionMapper.selectRandomByTypeAndDifficulty( courseId, 1, 2, mediumCount); // 抽取困难题 hardCount 道 ListQuestion hardList questionMapper.selectRandomByTypeAndDifficulty( courseId, 1, 3, hardCount); for (Question q : easyList) result.add(q.getId()); for (Question q : mediumList) result.add(q.getId()); for (Question q : hardList) result.add(q.getId()); return result; }这里有一个细节组卷时要把试卷包含的题目顺序固定下来然后学生考试时再对题目顺序做一次随机打乱。前者保证同一场考试每个学生面对的是同一套题后者防止邻座考生对答案。这是真实考试系统里很关键的设计答辩时讲出来老师会觉得你考虑到了实际场景。3.3 在线答题与倒计时实现在线答题页的核心是展示题目、记录答案、倒计时。前端用JavaScript实现一个简单的计时器每分钟或每30秒向后端发起一次请求同步学生的答题进度和后端记录的剩余时间。这个“心跳”机制非常重要否则学生答完交卷之前浏览器一刷新答题记录全丢了。具体做法是学生在考试开始时间点击“开始考试”后端在tb_exam_record里插入一条status1考试中的记录并记录start_time。前端页面用setInterval每30秒请求一次保存接口setInterval(function () { var answers collectAnswers(); $.post(/exam/saveProgress, { examId: examId, answers: JSON.stringify(answers) }); }, 30000);后端收到请求后更新tb_answer_detail表。这样就算学生没点交卷直接关了页面后端也有30秒内的最近一次作答进度。这个设计在论文里可以写成“答题进度实时保存机制”也算得上一个亮点。倒计时到了之后前端应自动禁用答题按钮并触发提交同时后端也要做好兜底在提交接口里判断当前时间是否已超过考试的start_time duration。前端禁用只是体验后端校验才是真正的保障。3.4 交卷与自动判分客观题秒出分主观题不头疼交卷的核心是判分。判分逻辑拆成两部分客观题单选、多选、判断——自动判分。系统遍历考试记录对应的所有答案明细逐一取出试题的标准答案和学生答案进行比对。单选题和判断题直接比对多选题要先把答案字符串排序再比对因为学生选择的选项顺序可能不同。多选题判分坑比较多。比如正确答案是ABC学生选了AB算全错还是算对一半我在设计时建议在试卷表增加一个字段multi_score_type来配置。但因为毕业设计场景里大部分老师是人工阅主观题为主客观题通常已有标准答案。全对才得分虽然严格但实现简单逻辑不容易被挑毛病。public int scoreObjectiveQuestion(Question q, String studentAnswer) { if (studentAnswer null || studentAnswer.trim().isEmpty()) { return 0; } if (q.getQuestionType() 1 || q.getQuestionType() 3) { return q.getAnswer().equalsIgnoreCase(studentAnswer.trim()) ? q.getScore() : 0; } if (q.getQuestionType() 2) { // 多选题排序后比较 String[] studentArr studentAnswer.trim().split(,); String[] rightArr q.getAnswer().split(,); Arrays.sort(studentArr); Arrays.sort(rightArr); return Arrays.equals(studentArr, rightArr) ? q.getScore() : 0; } return 0; }主观题则进入待批阅列表。教师端展示未批阅的考试记录逐题打分最后汇总总分。主观题判分不要尝试用NLP去搞“智能批改”那是研究生的课题方向超出毕业设计范畴了。保守起见设计成“客观题自动判分主观题人工批阅”混合模式既体现自动化又能说通业务。3.5 防止重复提交的并发细节在线考试系统虽然并发量不高但“重复提交”的问题一定会有。比如学生交卷时网络卡了一下他以为没提交成功又点了一次如果后端没有防重处理就会插入两条考试记录。解决办法有两层第一层是前端控制交卷按钮点击后立即置灰并禁用。第二层是后端幂等校验交卷接口里先根据exam_id和student_id查tb_exam_record如果status已经是2已交卷直接返回“请勿重复提交”。只要写两层就能兼备用户体验和逻辑正确。4. 论文、PPT与演示视频准备指南代码写完只是全部工作的一半。对于想要“高分”的毕业设计论文、PPT、演示视频这几样东西的分量至少占50%。甚至有些时候代码80分文档能把你拉到90分以上。4.1 Word论文结构参考与写作技巧一篇完整的在线考试系统毕业论文结构大致是这样的第一章 绪论选题背景与意义、国内外研究现状、主要工作。第二章 需求分析可行性分析、功能需求分析画用例图、非功能需求分析。第三章 系统设计总体架构设计B/S架构、功能模块设计、数据库设计E-R图、数据表说明。第四章 系统实现分模块贴关键代码和截图说明实现思路。第五章 系统测试测试环境、功能测试用例、测试结果分析。结论与展望总结工作提一两点不足和未来方向。写作时一个关键技巧是所有核心截图都要有文字说明不要光贴图。比如贴一张学生考试页面截图旁边要写清楚这个页面展示了哪些信息点击哪些按钮触发什么事件数据又是怎么流转的。评委翻论文时不可能像读小说一样逐字细读看到图文对照就会觉得工作量扎实。还有一件事容易被忽略软件工程文档。比如数据流图DFD、E-R图、用例图这些图一定要画。很多学校要求论文里必须有这些图你不用Visio也行用ProcessOn这类在线工具画完导出图片。画得规整一点能明显拉高分值。Word里的代码格式也要留意。不要截图代码而是用等宽字体插入。Word里建议使用“样式”里的“代码”样式或者调整字体为Consolas、9号字、单倍行距。代码过长的只贴核心片段注释用中文写下你的思路。4.2 PPT结构设计与答辩加分项答辩PPT不要做太多页。一般12到15页控制在8-10分钟的讲解时间。结构建议封面页题目、名字、学号、指导老师。目录页。选题背景与意义。核心功能需求。系统架构与技术选型一张图说清楚。数据库设计放E-R图或核心表说明。核心功能演示放三张截图学生考试页、自动判分结果页、成绩统计页。系统特色与难点放随机组卷、防作弊机制、实时保存这几个点。测试结论。总结与展望。PPT里一定要有“系统特色与难点”这一页这是答辩老师最爱问的地方。你在这页要准备几个能讲出来、讲清楚的问题。比如“你随机组卷怎么实现”、“如果两个学生同时交卷数据会乱吗”、“成绩怎么防止被篡改”——这些问题你的论文里有答案答辩前自己要能脱稿说一遍。演示环节是答辩的高潮。我强烈建议你写一份演示脚本演练至少三遍重点流程包括管理员登录创建课程 → 教师导入题库 → 教师组卷并发布考试 → 学生登录参加考试 → 学生交卷后查看客观题分数 → 教师批改主观题 → 学生看到最终成绩。整套流程走下来大约5分钟流畅展示可以留下相当好的印象。4.3 演示视频录制准备很多学校因为时间关系答辩现场没有时间让你完整演示改成提前录制视频。即使学校不强制要求我也建议你录一份演示视频放在项目文件夹里。答辩现场如果时间紧张老师可以直接看视频平时你自己复盘也方便。视频录制用OBS Studio或EV录屏分辨率1080p即可画面要包括系统界面和操作鼠标。操作过程中语速放慢一点边操作边讲。视频总长控制在10分钟以内导出MP4格式文件名建议按“系统名-演示视频-姓名”命名。5. 常见问题与排查技巧实录在线考试系统这种项目开发到后期、尤其是临近答辩时最容易冒出来一堆“怪问题”。其实真正出现频率高的大多集中在环境配置和细节逻辑上。我按自己的经验整理几个出现概率高的问题和排查思路供你参考。5.1 启动报错与数据库连接问题Spring Boot 启动时最常见的报错是数据库连接失败。报错信息是Access denied for user rootlocalhost (using password: YES)说明账号密码不对Unknown database exam_system说明数据库不存在或名字写错了。这些问题的排查方式很直接先用Navicat手动连一次MySQL确认账号密码和库名都能连通再回去看application.yml。配置文件里有一个常见的坑是时区问题连 MySQL 8.x 时在url后要加url: jdbc:mysql://localhost:3306/exam_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue不加serverTimezone启动可能报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。这类问题不是你的代码错是版本兼容问题遇到时先检查配置。端口占用也是高频问题。Spring Boot默认8080端口如果被其他程序占用启动会报Port 8080 was already in use。解决办法有两个一是在application.yml里改server.port8081二是找到占用进程结束掉。Windows下命令行执行netstat -ano | findstr 8080看到的那串数字就是进程PID再用任务管理器结束它。5.2 随机组卷结果不正确的问题有时候你设置单选题10道组出来的卷子却只有8道原因大概率是题库里符合条件的题目数量不够。当时我写组卷的时候也掉过这个坑难度为“难”的单选只有6道但组卷要求抽8道结果集合就是6道试卷题目数量自然不足。解决方式有两个方向一个是组卷接口返回时做一次校验抽取数量不足时直接报错提示“题库题目不足请先补充题目”另一个是组卷时放宽条件比如允许系统自动从下一级难度补题并记录日志。从毕业设计角度我建议用前者逻辑简单且对老师演示时好解释“这个接口做了校验”。如果不需要实时组卷而是提前生成试卷可以把题目不足的检测放在组卷提交时统一校验。5.3 多次点击提交产生重复成绩这个在演示中也非常容易暴露。你在点交卷按钮时如果手抖点了两下成绩列表里就出现了两条记录。原因就是前面说的没做前后端两层防重复提交。前端给按钮加disabled不够因为刷新后又能点了所以后端必须做幂等。在上面的交卷方法里加上ExamRecord record examRecordMapper.selectByExamIdAndStudentId(examId, userId); if (record ! null record.getStatus() 2) { return 你已经交卷请勿重复提交; }这个判断逻辑不复杂但非常重要一定要写到代码里。答辩现场老师拿着鼠标点来点去的情况很常见能防止这个坑演示会顺畅很多。5.4 中文乱码的排查思路中文乱码问题一般出现在前端页面显示、导出Excel或PDF报告、或管理员导入试题时。排查思路要分方向数据库层面库表字符集是否为utf8mb4。查看命令是SHOW CREATE TABLE tb_question;。项目层面Spring Boot中确保配置文件里的characterEncodingutf8。JSP或Thymeleaf页面里的meta charsetUTF-8。Tomcat层面如果用的是外部Tomcatconf/server.xml里修改Connector的URIEncoding为UTF-8。大部分乱码问题都是编码链不统一造成的。我的习惯是建库、建表、项目配置、页面声明这四处全部统一为UTF-8基本不会乱码。5.5 上传图片或富文本题目内容无法保存有些题目需要包含图片比如数学公式、几何图。一种做法是把图片转成Base64存在数据库这种做法在题库数据大了以后数据库会非常冗余而且Word里导出相当麻烦。更专业的做法是写一个文件上传模块把图片传到项目本地的一个upload目录数据库只存文件的访问路径。文件上传在Spring Boot里比较容易用MultipartFile接收上传文件保存到磁盘PostMapping(/upload) ResponseBody public String upload(RequestParam(file) MultipartFile file) { String originalFilename file.getOriginalFilename(); String fileName UUID.randomUUID().toString().replace(-, ) originalFilename.substring(originalFilename.lastIndexOf(.)); File dest new File(uploadPath fileName); file.transferTo(dest); return /upload/ fileName; }这里要注意一个点本地上传的文件夹路径不要写死成绝对路径比如“D:/project/upload”。因为毕业设计代码拷到别人电脑上运行时这个路径就失效了。更好的方案是使用配置项或者在项目类路径下建一个static/upload目录这样访问路径就是相对路径部署到任何机器都能正常展示图片。5.6 答辩演示前的环境检查清单答辩前一天务必按这个清单走一遍MySQL服务是否已启动数据库是否存在测试账号能否登录。Spring Boot项目能否一键启动启动后能否访问登录页。准备3-4套测试数据不同角色的账号确认状态可用。把演示要用的账号密码写在一张纸上放手机备忘录也行避免现场紧张忘掉。检查项目是否为最新代码演示机上是否已安装JDK和MySQL环境变量是否配置端口是否被占用。演示切换页面时数据库连接是否有超时问题——如果是长时间闲置后连接池失效导致白屏可在application.yml里给连接池配置较为宽松的超时参数或演示前先强制刷新一次登录页。演示环境建议用你开发用的那台电脑别临时换机器。如果必须换提前一天把整个环境搭一遍。现场卡在环境问题上是毕业设计演示最可惜的情况没有之一。写在后面的一点个人经验在线考试系统这类项目你做到最后会发现真正拉开分数差距的往往不是代码写得多么炫酷而是整条链路是否完整、文档是否规范、答辩是否讲得清楚。我个人在实际操作中的体会是先花两天时间把数据库表全部建好比你先写登录注册再回头补表效率高一倍。表结构稳了后面每个功能模块做起来都是顺水推舟的事。再一个建议就是完成一个模块就要截图写完一个功能就把对应代码高亮保存下来。这些东西是最后写论文的素材否则你代码写完了回头找截图还得重新启动系统再来一遍浪费时间不说个别状态还不好重现。在线考试系统的扩展空间其实很大比如引入缓存方案让并发压测更好看或者加一个学生端的小程序在答辩中都能形成一个新的话题点。先把基础版跑通再挑一两个点深入这套毕业设计拿高分是完全可期的。