企业官网建设流程全解析

1. 项目整体定位与设计思路

1.1 为什么是SpringBoot+Vue+MySQL这套组合

先说结论：这套组合放在今天依然是Web在线考试系统最稳、最不容易翻车的选型，没有之一。我做过的毕业设计辅导和外包项目里，凡是涉及“管理系统”“考试系统”“教务平台”这类题目，默认技术栈基本都是它，主要原因有三点。

第一，SpringBoot把Spring家族里那些繁琐的XML配置几乎全部干掉，起步就是一个可运行的jar包，对在校学生和刚入行的开发者非常友好。你不需要理解太多底层容器原理，写好Controller、Service、Mapper三层，业务逻辑就能顺畅跑起来。而且SpringBoot自带Tomcat，本地开发不用额外配服务器，IDE里点一下启动按钮就能看到效果。

第二，Vue是目前国内中小型管理系统前端事实标准，配合Element UI或者Element Plus，后台管理界面写起来速度极快。在线考试系统有大量表单、列表、弹窗、选项卡这类中后台交互，Vue的响应式数据绑定和组件化开发逻辑，天生就是为这种场景准备的。

第三，MySQL免费、稳定、资料多，大学课程里几乎人人都会。考试系统核心数据无非是用户、试题、考试记录、答题明细，MySQL的关系型模型完全够用，事务保障自动判分这类场景的数据一致性也很可靠。

另外，这套组合的“论文友好度”也特别高。SpringBoot、Vue、MySQL每一个都能在知网找到大量参考论文，需求分析、系统设计、数据库设计这些章节，素材多到写不完。毕业设计答辩时，老师看到的技术栈越主流，越不容易在选型层面追问刁钻问题。

1.2 系统角色与核心业务流程

在线考试系统表面看是“学生做题、老师出题”，但真正落地时至少要拆出三种角色：管理员、教师、学生。角色不同，面对的核心需求完全不一样。

管理员管的是“系统级”的事：账号管理、课程/班级管理、数据统计、系统参数配置。比如一个教师账号可以带哪些班级，一场考试允许几个人同时在线，这些都应该由管理员统一维护。

教师管的是“业务级”的事：创建考试、维护题库、手动组卷或随机组卷、批改主观题、查看成绩分析。教师是整个系统中操作最重的角色，很多毕业设计恰恰忽略了教师端的易用性，导致答辩时被老师说“功能太单薄”。

学生管的是“参与级”的事：查看待考列表、参加考试、查看成绩与试卷解析。这里面最关键的是考试体验——倒计时不能卡、交卷不能丢数据、答题卡状态要清晰、意外刷新页面后还能恢复答案。

整个系统的核心业务闭环是：教师创建考试 → 关联试题 → 发布考试 → 学生在规定时间内进入考试 → 系统自动判客观题、教师批主观题 → 学生查看成绩 → 教师导出成绩单。这个闭环听起来简单，真正实现时需要数据库、后端、前端三端协同配合，任何一个环节掉链子都会让整场考试崩掉。

2. 数据库设计与核心表结构

2.1 用户、考试、试题三大核心域

数据库设计是这类项目的命门。我自己见过太多人一上来就写代码，结果做到考试模块发现表结构撑不住业务，反过来重构，浪费大量时间。在线考试系统的表我习惯分成四个域来规划。

用户域：sys_user表存账号密码、姓名、角色类型（0管理员、1教师、2学生）；student表与用户表一对一关联，存学号、班级；teacher表存教师编号、所属教研室。如果系统规模不大，也可以直接在用户表里加一个class_name字段表示学生班级，省一张表。

考试域：exam表是核心中的核心，字段包括考试名称、开始时间、结束时间、考试时长（分钟）、总分、及格分、组卷方式（手工/随机）、是否允许重复考试、发布状态。exam_question是考试与试题的关联表，记录这道题在这份试卷中的分值、排序，这是随机组卷时必须存在的桥表。

试题域：question表存题干、题型（单选、多选、判断、填空、简答）、难度、所属课程、分值；question_option表存选项内容；主观题的答案存在question表自身，客观题的正确答案存在question_option表里，这样查询时逻辑更清晰。

答题域：exam_record表记录某位学生某场考试的整体情况，包括开始时间、交卷时间、客观题得分、总分、状态；answer_detail表记录每一道题的学生作答内容，与试卷最终得分一一对应。这两张表是成绩查询和试卷回顾的数据基础，一定要认真设计索引。

2.2 表关系与索引、编码注意事项

表关系上，exam_question和answer_detail这两张关联表，外键在物理上可以不加约束，但逻辑关系必须清楚。我在实际项目中通常保留逻辑外键，不加物理外键，因为学生交卷导出成绩时会有大量并发插入，物理外键在批量操作时会带来额外的约束检查开销，影响交卷性能。

索引设计有三个位置非常关键。第一，exam_record表上的(student_id, exam_id)必须建联合索引，因为“某学生是否参加过某考试”“某考试的全部参考学生”都是高频查询。第二，answer_detail表上的(exam_record_id, question_id)建联合索引，交卷后查看答题明细时避免全表扫描。第三，exam表上的start_time建普通索引，主页展示“进行中的考试”时需要按时间范围筛选。

编码问题几乎是每个新手都会踩的坑。数据库默认字符集一定要在建库时设为utf8mb4，排序规则用utf8mb4_general_ci。如果默认是utf8，学生在主观题里输入一个 Emoji 表情或者特殊符号（比如数学公式中的特殊字符），插入数据库直接报错，排查半天才发现是字符集问题。建库语句可以直接写死：

CREATE DATABASE exam_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

另外所有表的主键我习惯用BIGINT自增，不用 UUID。虽然分布式系统中 UUID 有意义，但毕业设计是单机部署，自增主键性能更好，排序也自然，前端分页时能少写很多逻辑。

3. 后端核心模块实现

3.1 SpringBoot分层结构与统一返回体

后端我采用经典的四层结构：controller → service → mapper → database。有人会问为什么不加一层 manager 或者 domain，其实对于在线考试系统这种业务规模，四层已经足够，再多反而变成为了架构而架构，答辩时也说不清。

统一返回体是后端开发里最容易被忽略的细节。如果没有统一返回格式，前端每个接口都要单独处理data、msg、code的差异，联调时改来改去。我的习惯是定义一个Result类：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String message) { ... } }

code我直接用 HTTP 业务码：200 表示正常，401 未登录，403 无权限，500 系统异常。前端拿到code后，如果发现是 401 就跳转登录页，是 403 就提示无权限，其余情况展示message。这样前后端契约非常清晰，联调效率高很多。

业务代码里特别要注意的是事务边界。比如教师创建一场随机组卷考试，涉及生成exam记录、批量插入exam_question关联记录，这两步必须放在同一个事务里，否则会出现“考试创建成功但试卷题目为空”的脏数据。我在ExamServiceImpl上使用@Transactional(rollbackFor = Exception.class)，确保任意一步异常都整体回滚。

3.2 登录认证与JWT令牌方案

在线考试系统的登录认证，我推荐用 JWT，而不是传统的 Session。原因有两个：一是前端是独立部署的 Vue 项目，前后端分离后 Session 跨域处理麻烦；二是考试系统天然有超时概念，JWT 的过期时间可以直接等同于登录态有效期，逻辑清晰。

JWT 接入步骤很简单，SpringBoot 引入jjwt依赖，登录成功后生成一个包含用户ID和角色信息的 token，前端把 token 存到localStorage，每次请求在请求头里带上Authorization: Bearer <token>。后端写一个拦截器统一校验：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录"); } // 解析token，放入ThreadLocal return true; } }

但这里有一个非常容易踩的坑：考试系统里学生可能要连续考两个小时，而 JWT 过期时间如果设置成 30 分钟，学生考到一半 token 过期，交卷请求被拦截，答案全部丢失。这绝对是不能接受的。我的解决办法是，进入考试页面时向后端申请一个“考试专用长时令牌”或者在后端白名单接口中放行“交卷”“提交答题记录”这类接口，不校验 token 有效性，只校验用户ID。毕业设计场景下更简单的方案是直接把 token 过期时间设置到 24 小时，毕竟是在校学生自用系统，安全性要求没有金融级那么高。

3.3 自动判分与组卷算法

自动判分是考试系统最核心的技术点，也是答辩时老师最感兴趣的部分。客观题判分逻辑不复杂，但细节决定成败。

单选题：学生选项与正确答案完全一致记满分，否则记 0 分。多选题：我采用的策略是“全对才给分”，选少、选多、选错均记 0 分。有老师要求“部分选对给一半分”，这个逻辑也能做，但需要额外定义打分规则，毕业设计阶段不推荐给自己加难度。判断题：学生选择答案与标准答案一致记满分。

判分的实现可以在学生点击“交卷”时一次性完成。遍历answer_detail表，每道题根据题型走不同判断逻辑，累加分数写入exam_record.total_score。这个过程用 SpringBoot 的异步任务处理也可以，但考虑到实际并发量不高，同步处理反而更稳，学生交卷后立即能看到成绩。

组卷算法有两种实现思路。手工组卷简单粗暴：教师从题库中勾选题目，存入exam_question表。随机组卷稍微讲究一点，需要按题型和难度比例抽取题目，核心 SQL 原理就是从题库中按条件查询后随机排序：

// 从题库中按课程、题型、难度条件，随机抽取指定数量题目 List<Question> questions = questionMapper.selectList( new LambdaQueryWrapper<Question>() .eq(Question::getCourseId, courseId) .eq(Question::getType, type) .eq(Question::getDifficulty, difficulty) .last("ORDER BY RAND() LIMIT " + totalCount) );

要注意ORDER BY RAND()在数据量超过十万条时性能会很差，但毕业设计系统题库也就几千道题，完全没问题。答辩时可以主动提一句“如果数据量增大我会改用基于随机数偏移量的优化方案”，反而加分。

4. 前端Vue实现要点

4.1 项目结构与路由权限控制

前端我用 Vue2 + Element UI 组合，原因很现实：Vue2 的教程、组件、踩坑资料全网最多，遇到问题搜索一下就能解决。Vue3 虽然新，但 Element Plus 的部分组件行为和 Vue2 有差异，自己研究起来成本高，毕业设计图稳不图新。

项目结构按业务模块划分：

src ├── api # 所有接口请求定义 ├── assets # 静态资源 ├── components # 公共组件（倒计时、答题卡、富文本等） ├── router # 路由配置 ├── store # Vuex状态管理 ├── views # 页面视图 │ ├── admin # 管理员页面 │ ├── teacher # 教师页面 │ ├── student # 学生页面 │ └── login # 登录页 └── utils # 工具函数（request封装、格式化等）

路由权限控制是前端面试常问的点，也是这个项目的亮点。我的做法是：路由表中直接写当前所有页面路由，但每个路由的meta字段里标记允许访问的角色，比如{ path: '/teacher/exam/create', meta: { roles: ['1'] } }。前端在路由守卫里获取当前用户角色，判断能否访问目标路由：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (!token && to.path !== '/login') { next('/login') } else { const roles = to.meta.roles if (roles && !roles.includes(localStorage.getItem('role'))) { next('/403') } else { next() } } })

注意：前端的路由权限控制更多是用户体验层面的拦截，真正的安全校验必须在后端接口上做，否则绕过前端直接调接口就能越权，这是答辩时的高频追问点。

4.2 考试页面：倒计时与答题卡

考试页面是整个前端最复杂的部分，我踩过的坑比后端加起来还多。核心就两个字：状态。

倒计时功能需要用定时器每秒更新剩余时间，我在examRoom页面中维护一个remainingSeconds变量，进入页面时根据考试截止时间和当前时间计算初次剩余值，然后用setInterval每秒减一。关键坑点是：学生切走浏览器标签页时，浏览器为了省电会降低定时器执行频率，页面回来时倒计时可能已经不准。解决办法是不要单纯依赖定时器减一，而是每次定时器触发时重新用Date.now()计算当前时间与截止时间的差值，保证准确。

答题卡是一个网格面板，展示每道题的答题状态。状态分为“已答”“未答”“当前”。我用answerStatus数组存储，元素值为true表示已答。学生点击选项时更新状态，答题卡上的格子颜色实时变化。这个交互看起来简单，但它是 Vue 响应式数据的典型应用，我一般会给面试官或者答辩老师展示这里的数据流：点击事件 → 更新studentAnswers数组 → 计算属性更新answerStatus→ 模板渲染格子颜色。

交卷按钮需要做二次确认弹窗，防止学生误点交卷。更完善的方案是提交前向后端发送一个“预交卷检查”请求，后端校验主观题是否未答、答题时间是否足够，但毕业设计做到“二次确认+校验未答题数”这一步已经足够亮眼。

4.3 axios封装与请求拦截

前端与后端对接时，axios 封装是必经之路。我在utils/request.js中创建一个 axios 实例，统一设置基础路径、超时时间和请求头：

const service = axios.create({ baseURL: '/api', timeout: 15000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code === 401) { localStorage.clear() window.location.href = '/login' return Promise.reject(new Error('未登录')) } if (res.code !== 200) { Message.error(res.message) return Promise.reject(new Error(res.message)) } return res }, error => { Message.error('网络错误，请稍后重试') return Promise.reject(error) } )

这里有个很实际的坑：考试交卷接口响应时间可能较长，如果学生网络不好，默认的 15 秒超时可能导致交卷失败。我的方案是交卷接口单独设置更大的超时时间，service.post('/exam/submit', data, { timeout: 60000 })。同时后端接口在提交试卷时应该做到幂等，比如同一学生同一考试的重复交卷请求直接返回上一次成绩，防止学生网络抖动后多次点击交卷产生多条记录。

5. 部署环境与上线流程

5.1 本地开发环境搭建

毕业设计要做到“拿过去就能跑”，环境搭建文档必须详细。我自己接手的项目里，至少有三分之一是“代码没问题但环境起不来”，罪魁祸首基本都是 JDK、Maven、Node 版本不一致。

后端环境建议：JDK 1.8（对应 SpringBoot 2.x）或者 JDK 17（对应 SpringBoot 3.x）。我的项目用 JDK 1.8 + SpringBoot 2.7.x，稳定性是经过无数生产项目验证的。Maven 用 3.6.3 或 3.8.x，安装后一定要配置阿里云镜像源，否则从中央仓库下载依赖的速度会把人的耐心磨光。settings.xml里加这段：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

前端环境：Node 14 搭配 npm 6，Vue CLI 5 以下版本跑起来最顺。如果直接装 Node 20 再跑老项目，很容易出现opensslErrorStack这类证书错误，报错信息网上五花八门，新手折腾半天。稳妥方案是装 Node 14.21.3，然后npm install一次成功。前端如果要播放视频、音频题目（比如英语听力），可以用 HTML5 原生video、audio标签，配合后端返回的流媒体地址。

5.2 前后端打包与部署

部署方式我推荐“前后端分离部署”：后端打包成 jar，前端打包成静态文件交给 Nginx 托管。

后端打包前先检查application.yml里的数据库连接信息，确认指向服务器上的 MySQL。然后执行：

mvn clean package -DskipTests

打包出来的 jar 放在服务器上，用nohup java -jar exam-system.jar > exam.log 2>&1 &启动。注意：如果服务器内存只有 1G，要加 JVM 参数限制内存使用，比如-Xms256m -Xmx512m，否则 SpringBoot 默认内存配置可能直接把服务器拖垮。

前端打包：

npm run build

生成dist目录，把里面的文件全部上传到 Nginx 的html/exam目录下。Nginx 配置两个关键点：第一是root路径指到dist目录；第二是处理 Vue 路由的 history 模式，需要把所有非静态文件请求都转发到index.html：

location / { root /usr/share/nginx/html/exam; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

/api/接口反向代理到后端 jar 所在端口，前端 axios 的baseURL配置成/api，开发环境通过 Vue CLI 的devServer.proxy转发到localhost:8080，生产环境通过 Nginx 转发，前后端联调无缝切换。

5.3 数据库初始化与迁移脚本

部署文档中最容易被忽略的部分是数据库脚本。很多人直接把数据库从本机导出一份 SQL 交给别人，结果对方导入时各种报错。

我习惯的做法是在项目根目录放一个sql/init.sql文件，里面包含完整的建库、建表、初始化数据语句，并且加上幂等处理。比如建表前先做判断：

DROP TABLE IF EXISTS `sys_user`; CREATE TABLE `sys_user` (...);

初始化数据要包含一个管理员账号、一个教师账号、一个学生账号，账号密码建议用 BCrypt 加密后的值预先写入，这样对方导入数据库后不用自己注册账号，直接就能登录体验系统。这是提升验收体验的小技巧，但效果非常明显——对方跑起来第一件事就是登录看看界面，如果还要自己注册账号，好感度直接减半。

另外，生产环境 MySQL 的max_allowed_packet参数如果太小，批量插入试题数据时可能会报错，建议在部署文档里提一句：set global max_allowed_packet = 16M;。

6. 论文结构与撰写经验

6.1 需求分析与系统设计章节怎么写得有亮点

论文的第一章往往是“绪论”，里面包含背景意义、国内外研究现状、研究内容。这段大家写得都很虚，答辩老师翻两页就跳过。真正拉开差距的是第二章“需求分析”和第三章“系统设计”。

需求分析章节，我建议用一个表格把功能需求列清楚：模块、功能描述、优先级、使用角色。比如考试管理模块包含“创建考试”“发布考试”“手工组卷”“随机组卷”“成绩统计”五个功能点，对应教师角色，优先级为高。这样写的优势是答辩老师一眼能看懂系统到底做了什么，比你用三页文字描述“系统可以实现在线考试功能”有效得多。

系统设计章节，除了画系统架构图、功能结构图，一定要有数据库 ER 图。Excel 画表结构其实也可以，但推荐用 PowerDesigner 或者 Navicat 的模型功能导出 ER 图。论文的 ER 图不需要特别复杂，把sys_user、exam、question、exam_record、answer_detail五张表的关联画出来就够有说服力了。注意：论文里别把物理外键约束画得太死，你实际代码中没加物理外键，ER 图里又画了关系线，答辩时容易自相矛盾，建议用“逻辑关系”标注。

6.2 测试章节这样写才不容易被追问

很多毕业设计的测试章节就是写“系统测试表明系统功能正常”，完全零分。真正可用的测试章节要包含：测试环境（JDK版本、数据库版本、浏览器版本）、测试用例表、测试结果分析。

测试用例表是最重要的内容。一行行写清楚：用例编号、测试功能、前置条件、操作步骤、预期结果、实际结果、是否通过。比如“测试学生正常交卷流程”这条用例，预期结果是“交卷成功后提示成功并显示成绩”，实际结果“与预期一致，测试通过”。一篇论文里写 20 条这样的测试用例，测试章节就显得非常扎实。

测试部分我的经验是：不要把用例写得全是“通过”。主动写两条“异常场景”并说明处理方案，效果反而更好。比如“考试时间结束未自动交卷”的用例，预期是“系统强制提交已答内容”，如果实际开发时确实做了这个逻辑，就如实写；如果没做，就在用例中写明“该场景已通过前端倒计时拦截”。答辩时可以说“对于超时未交卷，我们通过前端倒计时触发自动提交，后端也有时间校验兜底”，一下子就把系统的严谨性立起来了。

7. 常见问题与避坑实录

7.1 后端高频报错与解决方案

项目整体做完后，我在辅导别人运行这套系统时总结了几条最高频的报错，基本覆盖九成的新手卡壳点。

第一是数据库连接失败，报Access denied for user 'root'@'localhost'。这个九成是密码不对或者权限不对，但也有一种隐蔽情况是 MySQL 8.0 默认使用caching_sha2_password加密方式，而项目中用的数据库驱动版本不支持，导致连接失败。解决办法是把连接驱动升级到mysql-connector-java 8.0.x，或者在数据库执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '密码';。

第二是接口返回 404，页面白屏。前端开发时用代理转发，后端接口路径和前端请求路径对不上就会出现这个问题。排查路径很简单：打开浏览器 F12 看 Network 面板，看请求 URL 和后端 Controller 的@RequestMapping是否完全一致，尤其是/api前缀的层级关系。

第三是端口被占用。SpringBoot 默认端口 8080，如果本机装了其他服务占用，启动直接报错。要么在application.yml改端口，要么netstat -ano | findstr 8080找到进程杀掉。部署文档中一定要写清楚这一点，不然别人拿到项目后第一眼就看到报错，心态直接崩了。

7.2 前端高频问题与调试技巧

前端最容易出问题的就是跨域和接口数据格式不一致。

跨域问题表现是控制台报No 'Access-Control-Allow-Origin' header is present on the requested resource。开发环境直接用 Vue CLI 的proxy解决，生产环境用 Nginx 反向代理解决，这两种方式都属于“后端无感知跨域”，不需要在 SpringBoot 里配 CORS。如果你非要在后端配@CrossOrigin或者 CorsFilter，要注意allowCredentials(true)时不能用*通配域名，必须写具体地址，否则前端依然报跨域。

数据格式不一致问题最经典的场景是后端返回的时间字段是数组或者字符串，前端显示不对。比如LocalDateTime序列化后默认是"2024-06-01T10:30:00"，前端可能希望显示成"2024-06-01 10:30"。我在后端配置了统一的 JSON 时间格式化：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")

但要注意：如果这个字段是LocalDateTime类型，还需要在启动类或者配置类里注册JavaTimeModule，否则@JsonFormat可能不生效。这个细节是新手查半天也查不出来的那种坑。

7.3 数据库相关坑点：字符集、时区与并发

时区问题几乎每个跑这套系统的人都会遇到一次。SpringBoot 连接 MySQL 时，如果连接字符串里没有serverTimezone参数，高版本驱动会直接报错，或者时间数据差了 8 小时。我在application.yml里的连接写法是：

jdbc:mysql://localhost:3306/exam_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

serverTimezone=Asia/Shanghai必须写，否则容器时间和数据库时间对不上，考试开始和结束时间判断会出大问题。试想一下：数据库里存的考试时间是上午 9 点，后端判断当前时间时因为时区偏移认为现在是凌晨 1 点，学生 9 点半进考场系统直接提示“未到开始时间”，这属于逻辑没写错但环境配置坑死人的典型。

并发问题主要集中在“同场考试同时交卷”。虽然学校场景下并发量不高，但 60 个人的考场同时点交卷，对于一台普通机器还是有压力的。我的建议是交卷接口的判分逻辑尽量轻量化，不要在事务里做太重的统计查询，成绩汇总可以在交卷事务提交后，再用异步方式计算并更新到exam_record表，页面通过轮询或者学生主动刷新获取最终成绩。

7.4 多媒体题目的扩展方案

如果你做的考试系统涉及英语听力、视频题这类多媒体内容，打包部署时要注意静态资源的存放方式。最省事的方案是把音频、视频文件放在本地磁盘目录，后端通过WebMvcConfigurer添加一个资源映射：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/media/**") .addResourceHandler("file:" + mediaFilePath); }

前端直接用http://服务器地址:8080/media/audio001.mp3就能播放。如果题目包含大视频需要点播切片，可以用 MinIO 做对象存储，配上 Nginx 的流媒体模块，但整体复杂度会上升，纯毕业设计没必要。这里我可以明确告诉你，用本地静态资源映射足够完成演示，答辩时重点讲清“多媒体题目如何存储与访问”反而显得思考深入。

8. 这套系统还能怎么扩展

8.1 从毕业设计到可上线的差距

很多同学做完毕业设计会有个困惑：这套系统真的能直接给学校用吗？我的看法是，功能上已经能支撑一场几百人的校内考试，但离“生产可用”还有几个明显的距离。

第一是缺少考试防作弊机制。切屏监测可以简单实现，比如前端监听document.visibilitychange事件，记录学生切出页面的次数和时间，后端在成绩单中标记异常。人脸识别这种方案成本太高，但可以提一句“后续可以接入百度云人脸识别 API”作为扩展方向。

第二是缺少成绩分析可视化。目前系统只有成绩列表，如果增加一个 ECharts 图表页面，展示平均分、及格率、分数段分布、每道题正确率，这个系统在答辩和实际使用中的价值会直接上一个台阶。ECharts 与 Vue 的整合已经非常成熟，加一个v-charts组件库半天就能做完。

第三是缺少考试发布前审核流程。实际业务中教师创建考试后需要管理员审批，但这在毕业设计系统里不做也没关系，可以在论文的“未来展望”中提到。

8.2 代码结构上几个值得改进的点

站在代码质量角度，这套系统有几处以后接手的人一定会感谢你的设计。第一是异常处理集中化，我封装了一个GlobalExceptionHandler，用@RestControllerAdvice全局捕获业务异常，避免 Controller 里堆满 try-catch。第二是参数校验，后端接口入参用@Validated配合@NotNull、@NotBlank注解，前端传空参数时直接返回提示，不进入业务逻辑。第三是日志记录，利用 SpringBoot 自带的 Logback，在关键操作（创建考试、发布考试、交卷）处打印日志。

答辩时如果被问“你这个系统还有什么不足”，你可以很坦然地讲：目前随机组卷的算法只按题型和难度比例抽取，没有考虑知识点覆盖范围；交卷自动判分只覆盖客观题，主观题需要人工批改；系统目前是单体架构，未来学生量增长后可以考虑将考试服务单独拆分。这几个回答既展示了你有思考，又不会给老师留下系统有重大缺陷的印象。

9. 写在最后的实操体会

这整套系统从头到尾跟下来的最大感受是：在线考试系统不是一个“会写 CRUD 就能做”的项目，它的难点全在业务细节上。倒计时准不准、交卷丢不丢数据、随机组卷能不能控制难度、成绩统计正不正确——每一个都是看起来不起眼、但做不好就会被一眼看穿的点。

如果你正在做这个题目，我给你三个建议。第一，先花三天把数据库设计搞清楚，表之间怎么关联、哪些字段必须有、索引加在哪里，这些都定好了再写代码，效率至少要提升一倍。第二，前端页面不要追求花哨，把考试流程中最核心的“进入考试—答题—交卷—看成绩”体验做顺，比堆十个没有深度的页面有用得多。第三，部署文档一定要自己照着从零跑一遍，别写好之后自己不验证，等到验收时才发现少写了一步环境配置，那种尴尬我已经见过太多次了。

这套系统的价值不在于技术多前沿，而在于它把一套完整的业务闭环从头到尾打通了。你做完之后，SpringBoot 的后端分层、JWT 认证、事务控制，Vue 的路由守卫、组件通信、axios 封装，MySQL 的表设计和索引优化，这些能力都是实打实能写进简历的。哪怕以后不做毕业设计，这套实战经验在找工作面试时聊起来，也绝对比背八股文要有说服力得多。