简介：一套基于Java的在线考试系统完整毕业设计项目，采用SSM框架与Vue前端开发，适合计算机专业毕业设计或课程设计，也适合需要快速搭建考试系统的Java开发者参考。系统划分前台用户与后台管理员两大角色，覆盖首页、个人中心、考试成绩管理、公告通知、考生通知、题目管理、试卷管理、考试管理等模块，业务逻辑完整。资源包共534个文件，包含95个Java后端源码、43个Vue前端组件、34个XML配置、3个SQL数据库脚本以及编译后的class文件、启动脚本等，压缩包整体15.54MB。同时附带环境配置说明，支持JDK1.8、Tomcat7/8/9、MySQL5.7/8.0，可直接导入IDEA或Eclipse运行。已有159人学习下载，对希望掌握SSM+Vue整合开发、理解考试系统业务流转的读者很有帮助。
1. 在线考试系统为什么选 Java + SSM + Vue：从一个毕设题的选型说起
很多人在毕设选题表里看到“在线考试系统”时，第一反应是选 Spring Boot 加模板引擎直接渲染页面，理由是能少写一套前端。可真做下去就会发现，这类系统涉及管理员、教师、学生三种角色，页面形态完全不同；题库管理、自动组卷、在线答题、成绩统计彼此又强依赖数据，一旦把逻辑混在页面里，组卷和成绩统计会越改越乱。某高校一位同学最初用 JSP + Servlet 写了半个月，最后在这两块反复返工，换用 SSM 框架提供后端接口、Vue 构建前端页面后，一周打通全部主体功能。这套方案就是按“后端分层 + 前端组件化”组织的：源码、数据库脚本、配套论文齐全，覆盖从需求分析到验收答辩的完整链路。下面先讲总体架构如何拆分，再落到数据库、关键代码和最容易翻车的地方。
2. 总体架构设计：三层结构与核心模块的职责划分
2.1 整体架构：前后端分离下的 SSM 分层与请求链路
这套系统后端选的是 SSM，即 Spring + SpringMVC + MyBatis。不用更“新”的组合，是因为这个项目的角色权限和业务流程很典型，用成熟分层反而容易讲清楚：Spring 管理对象与事务，SpringMVC 负责路由与参数绑定，MyBatis 负责 SQL 映射，三者的边界恰好对应论文里“控制层、业务层、持久层”三段式写法。前端用 Vue 2 加 Element UI 构建，分学生端和管理端两套视图，共用同一组 REST 接口。
接口设计走得很常规：/api/user/login、/api/question/list、/api/paper/generate、/api/exam/submit、/api/score/list 等，每个接口统一返回 Result 结构，带 code、message、data 三个字段。前端 Axios 拦截这个结构，code 为 200 正常渲染，否则弹错误提示。一次交卷请求的完整链路是：
浏览器发起请求 → Vue Router 匹配路由 → Axios 发送到 Nginx → 动态请求转发到 Controller → Service 编排业务规则 → MyBatis Mapper 访问 MySQL → 结果逐层返回前端
这条链路在答辩时作用很大，因为能直接拿着它讲“一个考试请求经过哪些节点”。我见过不少同学把所有逻辑塞进 Controller，组卷接口还要依赖前端回传的题目列表，等于把系统弹性放弃了。分层之后各层职责非常干净：Controller 不写 SQL，Mapper 不做业务判断，Service 只编排规则和事务边界。
前后端分离还有一个实际好处：学生端答题页和管理端题库页是两套路由，但接口是同一套。管理员在管理界面录入一道题，学生端刷新就能用；如果前后端耦合，这种多入口场景就要写两遍路由和控制逻辑，代码量至少多出三成。
2.2 核心功能模块：从题库管理到成绩统计的五条业务线
我习惯把系统拆成五条业务线，每条对应一套表和一组接口，这也是写论文目录时最好用的组织方式。
第一条线是用户管理。管理员可以新增、禁用、重置教师和学生账号；教师可以查看所授课程的学生列表。登录后按角色跳转不同首页：管理员看到题库统计和组卷入口，教师看到课程与试卷列表，学生看到待参加的考试。
第二条线是题库管理。核心是单选题、多选题、判断题、填空题的增删改查与批量导入。每道题带题型、难度、知识点、分值四类属性，这四个字段是自动组卷的主要依据，所以建表时就必须给足，不能后面再加。
第三条线是试卷管理。教师选择课程后，配置试卷标题、总时长、总分和题型结构，例如“单选 20 道每题 2 分、多选 10 道每题 3 分、判断 10 道每题 1 分”。系统按这套规则自动抽题生成试卷，生成后可预览，也可以手动替换任一题目。
第四条线是在线考试。学生进入考试页后计时器开始，题目分页展示，切换题目时答案先存本地，交卷时一次性提交。考试期间禁止复制粘贴和离开页面，刷新后从服务端恢复答题状态。
第五条线是成绩管理。交卷后自动判分并写入成绩记录。教师查看班级成绩单和每道题的正确率，学生只能看到自己和答错的题。这五条线串起来正好是一次考试的完整闭环：建账号 → 录题 → 组卷 → 考试 → 出分。
2.3 Spring + SpringMVC + MyBatis 集成方式与配置要点
集成第一步是写 Spring 的 applicationContext.xml，管理数据源、事务和 Mapper 扫描。
<!-- Spring 核心配置：数据源与事务管理 --> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/exam_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai" /> <property name="username" value="root" /> <property name="password" value="123456" /> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="mapperLocations" value="classpath:mapper/*.xml" /> <property name="typeAliasesPackage" value="com.exam.entity" /> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.exam.mapper" /> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean> <tx:annotation-driven transaction-manager="transactionManager" />这里有几个参数值得说明。url 里的 serverTimezone 必须写，否则 MySQL 8 驱动会报时区错误；mapperLocations 指向 XML 文件目录，typeAliasesPackage 让实体类在 Mapper XML 里可以写短类名；事务管理器绑定同一个数据源，保证交卷评分这样的多步操作要么全成功、要么全回滚。
再配置 SpringMVC 的入口，在 web.xml 里注册 DispatcherServlet：
<servlet> <servlet-name>springmvc</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:springmvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>springmvc</servlet-name> <url-pattern>/api/*</url-pattern> </servlet-mapping>注意这里用 /api/* 而不是 /，这是故意设计的。前端打包后的 dist 目录交给 Nginx 访问，后端只响应 /api 开头的请求，这样接口和静态页互不干扰，也缩小了安全校验的检查范围。MyBatis 的 XML 文件里，namespace 必须跟 Mapper 接口全限定名一致，否则启动就报绑定异常，这是最容易漏的一步。
最后是容器层级约束：Spring 容器是父容器，SpringMVC 容器是子容器。springmvc.xml 只扫描 Controller 所在包，applicationContext.xml 扫描 Service 和 Mapper 包，不能交叉，否则事务代理失效，交卷时数据会写一半丢一半。
3. 数据库设计：八张业务表如何支撑一次完整的在线考试流程
3.1 概念模型：用户、课程、题库、试卷、考试记录五条主线
数据库是这套系统最值得花时间设计的部分。八张表分别是 tb_user、tb_course、tb_question、tb_paper、tb_paper_question、tb_exam_record、tb_answer_detail、tb_score，它们之间的关系可以用五条主线来理解：
用户与课程是多对多关系，中间表就是 tb_user_course，一个教师可以教多门课，一门课可以有多个教师和学生；题库挂在课程下，一道题属于某门课程；试卷也挂在课程下，一张试卷通过 tb_paper_question 关联多道题；考试记录挂在试卷下，一次考试对应一条记录；答题明细与考试记录是一对多，每道题写一条明细；成绩从答题明细汇总而来，写入 tb_score，成为最终对外展示的数据。
这样设计的核心目的是保持成绩可追溯。如果只存一个总分，导师问“某道题错在哪、学生答了什么”，论文和系统都答不上来；有了答题明细表，每个答案、每道题得分都能回溯。对毕设而言，这种“细节可查”恰恰是评分点，比炫技的数据结构实在得多。
3.2 核心表结构设计：字段、索引与约束说明
题库表和试卷关联表是设计的重心。题库表直接决定组卷逻辑的实现难度：
CREATE TABLE tb_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '题目主键', course_id BIGINT NOT NULL COMMENT '所属课程', question_type TINYINT NOT NULL COMMENT '题型：1单选 2多选 3判断 4填空', difficulty TINYINT NOT NULL COMMENT '难度：1易 2中 3难', knowledge_point VARCHAR(100) NOT NULL COMMENT '知识点标识', content TEXT NOT NULL COMMENT '题干', options TEXT COMMENT '选项JSON，单选多选才有', answer TEXT NOT NULL COMMENT '标准答案', score DECIMAL(5,2) NOT NULL COMMENT '单题分值', creator_id BIGINT NOT NULL COMMENT '录入教师ID', status TINYINT DEFAULT 1 COMMENT '1启用 0禁用', create_time DATETIME NOT NULL COMMENT '录入时间', INDEX idx_course_type (course_id, question_type), INDEX idx_difficulty (difficulty) ) COMMENT='题库表';选项字段存 JSON 是被问到最多的设计决定。为什么不拆成选项表？因为单选、多选、判断的选项结构不统一，拆表要处理三种形态，考试时还要多次连表查询；存 JSON 的做法是让前端负责解析，后端只做透传，开发成本低，也能满足毕设场景。如果追求规范化，可以在论文的“改进方向”里提一句，效果更好。
试卷与题目的关联表是另一个关键设计，它的字段决定了组卷时能不能正确处理分值和顺序：
CREATE TABLE tb_paper_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, paper_id BIGINT NOT NULL COMMENT '试卷ID', question_id BIGINT NOT NULL COMMENT '题目ID', question_order INT NOT NULL COMMENT '题号顺序', score DECIMAL(5,2) NOT NULL COMMENT '该题实际分值', INDEX idx_paper (paper_id), UNIQUE KEY uk_paper_question (paper_id, question_id) ) COMMENT='试卷题目关联表';question_order 是题目在试卷里的显示顺序，score 字段允许同一道题在不同试卷里赋不同分值，这样复用度高。unique 约束防止同一张试卷重复关联同一道题。考试记录表和答题明细表按前面说的五条主线去建，核心就是外键加 status 状态位。交卷状态用 0 未开始、1 考试中、2 已交卷、3 已批阅四种状态不断推进，避免用布尔值导致状态无法扩展。
3.3 事务与并发：交卷场景下数据一致性的保证
在线考试系统最容易出问题的场景是并发交卷。一个班 40 人同时点交卷，如果后端没有事务保护，答题明细可能只插入一部分，成绩汇总丢题，甚至同一条考试记录被重复更新，分数错乱。
交卷接口必须加 @Transactional(rollbackFor = Exception.class)，并在方法开头检查考试状态。这样做的含义很明确：要么全部插入答题明细并且更新成绩成功；要么任何一步异常，所有写操作回滚，前端收到失败提示后可以重新提交。数据库侧的并发控制通过行锁实现，更新考试记录时用条件更新：
UPDATE tb_exam_record SET status = 2, score = #{score} WHERE id = #{recordId} AND status = 1;这条 SQL 的巧妙之处在于 where 条件带 status = 1，意味着只有“考试中”的记录能被更新为“已交卷”。两个并发请求同时进来时，MySQL 行锁会让第二个请求等待，第一个提交后 status 已经变成 2，第二个再执行时受影响行数为 0，直接在代码里判断 updates == 0 就返回“重复提交”。这是给并发交卷上的一道保险，比在 Java 代码里用同步锁简单得多，也更容易在答辩时讲清楚。
4. 核心模块实现：登录鉴权、自动组卷与在线答题的关键代码
4.1 登录与角色鉴权：SpringMVC 拦截器加 Redis 会话控制
登录接口的逻辑很直接：校验用户名密码、查用户状态、写入会话。真正需要小心的是密码这一环，明文存库在答辩现场被问到会很难堪，所以密码字段存的是 MD5 加盐后的结果，盐是每个用户独立的随机字符串，注册时生成并存到用户表。
// 登录接口核心逻辑 @PostMapping("/login") @ResponseBody public Result login(@RequestBody LoginDTO dto, HttpSession session) { if (StringUtils.isBlank(dto.getUsername()) || StringUtils.isBlank(dto.getPassword())) { return Result.error("用户名和密码不能为空"); } User user = userMapper.selectByUsername(dto.getUsername()); if (user == null) { return Result.error("用户不存在"); } // 用当前用户盐值计算MD5，与库中值比对 String md5Pwd = md5(dto.getPassword() + user.getSalt()); if (!user.getPassword().equals(md5Pwd)) { return Result.error("用户名或密码错误"); } if (user.getStatus() == 0) { return Result.error("账号已被禁用，请联系管理员"); } session.setAttribute("loginUser", user); session.setAttribute("role", user.getRole()); return Result.ok(user); }登录接口的参数校验放在第一层，密码比对放在第二层，状态判断放在第三层，这个顺序是为了避免无效请求打到数据库。session 里同时存用户对象和角色值，拦截器只需要读 role 字段做权限判断。
角色鉴权用 SpringMVC 的 HandlerInterceptor 实现。拦截器里读取 session 中的 role，再判断当前请求的 URL 前缀：/admin/** 要求 role 为 1 或 2，/student/** 要求 role 为 3，不匹配就返回 401 JSON。配置上要排除 /login、/static 和 /error 这几个路径，否则前端的静态资源也被拦截，页面白屏。这里有个血泪经验：拦截器排除列表一定要把 favicon.ico 和 /assets 目录加进去，血的教训来自一次演示现场，图片加载失败导致页面布局全是乱的。
4.2 自动组卷算法：按题型、难度、知识点抽题的实现
组卷是这个系统里技术含量最高的模块，不需要什么花哨算法，关键在于抽题逻辑要稳定、可解释。这里用的是“分层随机抽题”：先按题型把题库切块，再在每种题型内部按知识点和难度过滤，最后从候选池里随机抽指定数量。
// 组卷核心方法：按题型分层随机抽题 public List<Long> selectQuestions(PaperRule rule) { List<Long> selectedIds = new ArrayList<>(); // 遍历题型分发规则，如：单选题要抽20道 for (PaperTypeItem item : rule.getTypeItems()) { // 按知识点与难度组合出候选池 List<Long> pool = questionMapper.selectCandidates( item.getQuestionType(), item.getKnowledgePoints(), item.getDifficulty()); // 候选数量不足时降低难度过滤条件，扩大候选池 if (pool.size() < item.getCount()) { pool = questionMapper.selectCandidates( item.getQuestionType(), item.getKnowledgePoints(), null); // 难度传null表示不限制 } // 随机打乱后取前N道 Collections.shuffle(pool); int need = Math.min(item.getCount(), pool.size()); selectedIds.addAll(pool.subList(0, need)); } return selectedIds; }这段逻辑的关键在两次查库的降级策略。第一次严格按难度和知识点查，第二次去掉难度条件，保证“尽量满足知识点要求但不至于出题失败”。如果题库里某个知识点确实没有任何题，第三种兜底是直接把该知识点从规则里剔除掉并记录 warning，这样组卷不会崩溃，教师能看到提示。
相应的 Mapper SQL 用动态查询实现，难度为空时忽略该条件：
<select id="selectCandidates" resultType="long"> SELECT id FROM tb_question WHERE course_id = #{courseId} AND question_type = #{questionType} <if test="knowledgePoints != null and knowledgePoints.size() > 0"> AND knowledge_point IN <foreach collection="knowledgePoints" item="kp" open="(" separator="," close=")"> #{kp} </foreach> </if> <if test="difficulty != null"> AND difficulty = #{difficulty} </if> AND status = 1 </select>抽完题目后还要经过一道排序和赋值：按题目 ID 的哈希值决定显示顺序，并按题型规则给每道题写入 tb_paper_question 的 score 字段。这一步必须在代码里完成，因为数据库不保证查询结果的顺序对用户有意义。最后把整张试卷的题目列表返回给前端预览，教师可以逐题替换。
4.3 在线答题与交卷评分：前端 Vue 与后端 Java 的配合
在线答题页是整个系统前端交互最复杂的部分。题目按题型区分渲染组件，单选题用 el-radio-group，多选题用 el-checkbox-group，判断题也用 radio 但选项固定为“正确/错误”。答案不实时提交，而是存在 Vue 组件的 answers 对象里，切换题目时写入 localStorage，刷新后能从缓存恢复。
<template> <div> <div v-for="(item, index) in questions" :key="item.id"> <h4>{{ index + 1 }}、{{ item.content }}</h4> <!-- 单选题渲染 --> <el-radio-group v-if="item.questionType === 1" v-model="answers[item.id]"> <el-radio v-for="opt in parseOptions(item.options)" :key="opt.label" :label="opt.label"> {{ opt.text }} </el-radio> </el-radio-group> <!-- 多选题渲染 --> <el-checkbox-group v-else-if="item.questionType === 2" v-model="answers[item.id]"> <el-checkbox v-for="opt in parseOptions(item.options)" :key="opt.label" :label="opt.label"> {{ opt.text }} </el-checkbox> </el-checkbox-group> <!-- 判断题渲染 --> <el-radio-group v-else-if="item.questionType === 3" v-model="answers[item.id]"> <el-radio label="T">正确</el-radio> <el-radio label="F">错误</el-radio> </el-radio-group> </div> </div> </template>这里最容易出错的是 v-model 的绑定值。单选题 v-model 绑定的是字符串 label，提交到后端的是 A、B、C 这种选项标号；多选题绑定的是数组，交卷时需要 join 成一个字符串再提交。如果前端没做这个转换，后端按字符串解析答案时多选永远判不对。解决办法很简单：在提交前统一把数组答案转成逗号分隔的字符串。
交卷评分是系统里对事务要求最高的方法，后端逐题判分并写入答案明细：
// 交卷评分：事务内判分并更新成绩 @Transactional(rollbackFor = Exception.class) public ExamResultVO submitExam(SubmitDTO dto, User student) { ExamRecord record = examRecordMapper.selectById(dto.getRecordId()); if (record == null || record.getStatus() != 1) { throw new BusinessException("考试状态异常，无法交卷"); } if (record.getEndTime().isBefore(LocalDateTime.now())) { throw new BusinessException("考试已结束，不能交卷"); } List<AnswerDetail> details = new ArrayList<>(); BigDecimal total = BigDecimal.ZERO; for (AnswerItem item : dto.getAnswers()) { Question q = questionMapper.selectById(item.getQuestionId()); BigDecimal score = judgeScore(q, item.getStudentAnswer()); total = total.add(score); AnswerDetail detail = new AnswerDetail(); detail.setRecordId(record.getId()); detail.setQuestionId(q.getId()); detail.setStudentAnswer(item.getStudentAnswer()); detail.setCorrectAnswer(q.getAnswer()); detail.setScore(score); detail.setIsCorrect(score.compareTo(BigDecimal.ZERO) > 0 ? 1 : 0); details.add(detail); } answerDetailMapper.batchInsert(details); int updated = examRecordMapper.submitForScore( record.getId(), total, student.getId()); if (updated == 0) { throw new BusinessException("重复交卷，请勿刷新页面"); } return new ExamResultVO(record.getId(), total); }这里注意 judgeScore 方法对多选的判分策略：完全一致给满分，部分一致按选项数比例给分，这一策略在论文里可以单独写一段。判分完后先批量插入答题明细，再更新考试记录状态和总分，两条写操作在同一个事务里，任何一步失败都会回滚，杜绝只插入明细不更新成绩的中间状态。
5. 常见问题排查：组卷失效、并发交卷、Session 过期等考点里的翻车点
5.1 组卷结果不稳定：两次生成数量不一致
现象：同一套组卷规则执行两次，第一次生成 50 题，第二次 45 题，甚至某题型直接为 0。
原因：题库过滤条件太严格，候选池数量小于需求数量，而代码里直接 subList(0, item.getCount())，数量不足时抛异常或静默取全部。多数情况下是知识点的题目录入不全。
解决：组卷前先统计每个分组的候选数量，不足时走降级逻辑，去掉难度条件再抽一次；还不满足就记录 warning 并在前端提示。我一般会在组卷页面显示“当前题库可用 48 题，需求 50 题”，把问题暴露在界面上，而不是让教师对着空卷子猜。
5.2 交卷时分数不对：并发提交导致成绩丢失
现象：全班同时交卷，部分学生成绩为 0 或只有一半题目的分数。
原因：交卷接口没加事务，或没有状态校验。两个请求同时到达，都读到 status=1，都执行 update，后者覆盖前者，答题明细只插入了一部分。
解决：给交卷方法加事务并把状态更新带上 status=1 条件。更新返回 0 时说明已被处理过，直接抛“重复提交”。答辩时最好把 MySQL 的锁机制讲一句：行锁会让后到的更新等待，这是最基础也最可靠的并发控制手段。
5.3 Session 过期：考试中途被踢出系统
现象：学生答题超过 30 分钟后提交，提示未登录，所有答案丢失，界面跳回登录页。
原因：容器默认 Session 超时时间短，或者考试时长本身超过 Session 生命周期。前端虽然有 localStorage 备份，但提交请求时 session 已经无效。
解决：把 Session 超时时间设成大于最大考试时长，比如在 web.xml 里配置 session-timeout 为 120 分钟。更稳的方案是加一个考试 token：进入考试时生成 token 传给前端，提交时用 token 换用户身份，不依赖 Session。毕设阶段用前者足够，后者写到论文的改进方向里会显得更有深度。
5.4 数据库连接池耗尽：批量导入题库时系统不响应
现象：用 Excel 批量导入 500 道题，导入过程中页面卡死，其他同学也访问不了系统。
原因：批量导入的 for 循环里逐条 insert，每道题占用一次连接，加上事务提交方式不对，连接池 20 个连接全被占满。
解决：改 MyBatis 的 batch 模式，500 条题只占一个会话，分三批提交。代码里用 SqlSession 的 ExecutorType.BATCH，提交后再手动 flushStatements。批处理一次写完还能顺带提升导入速度，从十几秒降到两三秒，这个优化在答辩现场演示格外加分。
5.5 Vue 组件数据不同步：切换题目时选项残留
现象：第一题选了 C，翻到第二题时第一题的选中状态还在界面上，或者多选题切到单选时保留了数组数据。
原因：v-model 绑定的 answers 对象是响应式的，但题目变化时没有清空上一题的答案对象；多选和单选共用 answers[item.id] 字段，类型切换时没有做数据重置。
解决：在题目切换的 watch 或方法里，重新初始化 answers 对象，并把上一题答案同步到 localStorage；进入新题时根据题型重置数据结构。代码里定义一个 resetAnswer(itemId, type) 方法，在 change 事件中调用。这个 bug 特别隐蔽，因为单机调试时不容易触发，一旦学生快速切题就会暴露，建议做验收测试时重点压测。
6. 验收与答辩：从功能测试到现场演示的完整走查清单
答辩前一个月，项目就不要再加新功能了，应当把时间花在走查上。我通常建议按下面清单过三遍：第一遍按角色过功能，第二遍模拟异常和边界，第三遍对着论文检查截图。
功能走查从学生视角开始：注册账号 → 登录 → 进入待考列表 → 开始考试 → 切题作答 → 交卷 → 查看成绩。每一步都要截图保留，论文里“系统实现”章节用的就是这些图。接着用教师账号登录 → 建课程 → 录题 → 配试卷规则 → 预览试卷 → 查看班级成绩单。最后用管理员账号重置密码、禁用账号、查看统计。
异常走查重点测三类场景：考试时间到了再交卷、重复提交同一份答卷、题目数量不足时组卷。这三类问题在答辩现场被追问的概率接近百分之百，回答时要先说结论再加一句实现细节。比如“时间结束后后端还会校验 endTime，超时直接拒绝”，比空泛的“做了校验”更可信。
演示顺序也有讲究：先跑通一个完整闭环展示系统功能，不要一上来就贴代码或者讲架构。考官看到实际效果后，再讲设计就有一层信任基础。我自己的习惯是每次演示前都强制走一遍这个闭环，从注册学生开始，不跳过任何一步，因为演示时最容易翻车的不是代码bug，而是忘记提前初始化题库、账号过期这类环境问题。直到现在，每次给导师或评审演示，我都还要先打开数据库确认连接池和测试账号状态，再开始走查。这个习惯帮我避免过多次现场翻车，也希望帮到你。
答辩讲解时按五条业务线展开，每条线说清楚三件事：数据从哪来、经过哪些处理、结果到哪去。掌握了这套逻辑，即使被问到没准备过的细节，也能顺着数据流向找到答案。
本文还有配套的精品资源，点击获取
