每年这个时候，都有一批人对着毕设题目发愁。如果你拿到的是“基于SSM+Vue的交通规则考试系统”这个题，恭喜你，这套组合拳在毕设圈里属于最稳的一类：后端是Spring+SpringMVC+MyBatis这套老牌SSM组合，前端是Vue，功能对标驾考宝典的科目一科目四，既没有花哨到答辩老师看不懂的技术，也没有脱离项目硬凑的鸡肋模块。它不是那种轻松到没有含金量的增删改查演示项目，但也绝没有难到让你熬夜掉头发的程度。
这篇文章我不打算给你堆理论，而是直接从“我怎么做这个项目”的角度，把设计思路、数据库表结构、后端注解的用法、前端页面怎么组织、联调部署踩的坑、甚至论文怎么配合程序去写，全部摊开来讲一遍。看完你能直接照着搭出框架，剩下的工作量就是填业务代码。
1. 项目整体设计与技术选型思路
1.1 为什么是SSM+Vue而不是SpringBoot+纯模板
先说技术选型。2026年了，SpringBoot早就成了主流，但毕设题目的SSM组合并不会消失，反而因为“够经典”被各大高校的题目库一直保留。既然题目里写明了SSM，那论文里的设计部分其实更好写——SSM三层架构（表现层、业务层、持久层）本身就是教科书级别的分层范例，答辩老师想问你架构思想，你照着三层拆开讲就行，一点都不会虚。
那前端为什么用Vue？因为Vue的渐进式设计太适合这种后台管理+前台考试的类型项目了。管理端的题库维护、用户列表、成绩统计，天生就是组件化开发的最佳场景；考生端虽然以考试界面为主，但Vue的响应式数据绑定让“下一题”、“标记未答”、“提交试卷”这些交互实现起来非常直观。这里我更推荐Vue 2.6+Element UI的组合，不是Vue 3不好，而是Vue 2的教程多、面试题库全、踩坑的答疑一搜一大片，毕设阶段求稳比求新重要。
还有一个很现实的理由：SSM + Vue前后端分离这个组合，既是Java Web课程的延伸，又包含了现在企业里常见的前后端分离开发模式，在毕设答辩里能说的点非常多。你要是用JSP+Servlet，答辩老师觉得你太老派；要是纯SpringBoot+Thymeleaf，又少了“分离开发”这个话题。SSM+Vue恰好卡在了一个既有教学意义又贴近行业实践的中间位置。
1.2 系统角色与整体业务流程
拿到一个题目，先别急着写代码，第一件事是把角色和流程捋清楚。交通规则考试系统乍一看就是“登录、做题、交卷、看分”，但作为一个完整毕设，必须有数据的源头和管理的链条。
我的设计里规划了三种角色：
- 考生：注册登录后，可以进行顺序练习、随机练习、模拟考试，查看考试记录和个人错题本。
- 管理员：负责题目和规则分类的维护，包括录入、修改、删除、批量导入，还可以管理用户账号、查看所有考生的成绩汇总。
- 系统：负责自动组卷、计时、自动评分、错题统计这些逻辑层面的工作。
整个业务闭环是这样的：管理员在后台录入题库（按分类：交通信号、标志标线、法律法规、安全常识等）→ 考生登录系统选择练习或考试模式 → 考试模式按规则随机抽题生成试卷 → 考生答题并交卷 → 系统自动判分并记录答题明细 → 答错的题自动进错题本 → 考生可以再做错题练习。这个流程覆盖了“数据产生→数据消费→数据沉淀→数据再利用”的完整链路，论文里写业务流程的时候会非常顺畅。
2. 功能模块的划分与边界设计
2.1 考生端功能模块
考生端是系统的门面，你说到底是个考试系统，考生端的体验直接决定了项目演示效果。我建议按四个模块来做。
练习模块：分开顺序练习和随机练习两种模式。顺序练习按题库的ID排序逐题作答，适合刚入门的人按章节刷题；随机练习则从题库中任意抽取，适合巩固阶段。这两种模式属于“轻量版考试”——做一题提交一题，即时反馈对错，并且给出正确答案和解析。
模拟考试模块：这是系统的核心亮点。考生点击开始考试后，系统按预设规则（比如100道题、45分钟、满分100分、每题1分）从题库中随机抽取题目生成试卷。考试期间显示倒计时，到时间自动交卷。交卷后系统自动评分，并展示得分、正确率、错题解析。
成绩查询模块：按时间倒序列出该考生的历史考试记录，包括考试时间、考试类型、得分、用时、是否通过。这个模块虽然简单，但能直观体现数据积累的过程。
错题本模块：考试和练习中答错的题目自动收录进来，支持查看错题原题、你的错误答案、正确答案和解析。错题可以一键移除（表示你已掌握），也可以从这里进入错题重做模式。
2.2 管理端功能模块
管理端不需要花哨，关键是效率和管理面完整。
用户管理：管理员查看所有注册考生的列表，支持按用户名模糊搜索，可以启用/禁用账号，重置密码。这里要注意一点，管理员账号不走注册接口，而是初始化项目时直接在数据库中写入，避免被注册接口覆盖权限。
题库管理：按分类浏览题目，支持新增、编辑、删除、批量导入导出。批量导入用Excel是最实用的方案——管理员可以按模板整理几百道题，一次性导入，对毕设展示来说效果很好。
分类与规则管理：题目分类维护（新增分类、修改名称、删除空分类），以及考试规则的配置，比如试卷中各类题目的数量、考试时长、及格线。把“考试规则可配置化”这个设计写进论文，比写死100道题的代码逻辑要高级不少。
成绩统计模块：用表格展示所有考生的考试记录，可以按用户名检索，也可以按及格/不及格筛选。再加上一个饼图或柱状图展示错误率最高的题目分类——这个统计功能用ECharts实现非常快，又能为论文增加“数据分析”的章节素材。
2.3 模块之间的解耦思路
前后端分离开发的天然优势就是把模块拆得更彻底。后端按职责分为Controller层、Service层、Mapper层，前端则把页面按路由划分成独立的视图组件。我在做的时候刻意维护了一条原则：前端页面只通过API与后端交互，后端只返回JSON数据，绝不直接在服务端渲染页面。这样带来的好处非常直接——后面想换前端框架、或者想加移动端适配，后端代码一行都不用动。
3. 数据库设计：核心表结构与实践详解
3.1 六张核心表的字段设计
数据库是后端设计的地基。我用了六张表来支撑整个业务，不多不少，刚好覆盖所有需求且让ER图清晰好画。
用户表（sys_user）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| username | varchar(50) | 登录名，唯一索引 |
| password | varchar(100) | 加密存储（MD5/BCrypt） |
| nickname | varchar(50) | 昵称 |
| role | int | 1=管理员，2=考生 |
| status | int | 1=正常，0=禁用 |
| create_time | datetime | 注册时间 |
规则分类表（rule_category）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| category_name | varchar(50) | 分类名（如交通信号） |
| category_desc | varchar(255) | 描述 |
| sort_order | int | 排序号 |
试题表（question）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| category_id | bigint | 关联分类表 |
| question_type | int | 1=判断题，2=单选题 |
| question_content | text | 题干 |
| option_a | varchar(255) | 选项A |
| option_b | varchar(255) | 选项B |
| option_c | varchar(255) | 选项C |
| option_d | varchar(255) | 选项D |
| correct_answer | varchar(10) | 正确答案（A/B/C/D 或 对/错） |
| analysis | text | 题目解析 |
考试试卷表（exam_paper）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| user_id | bigint | 考生ID |
| paper_name | varchar(100) | 卷名 |
| total_questions | int | 总题数 |
| total_score | int | 总分 |
| pass_score | int | 及格线 |
| duration | int | 考试时长（分钟） |
| start_time | datetime | 开始时间 |
| submit_time | datetime | 交卷时间 |
| score | int | 得分 |
| status | int | 0=考试中，1=已交卷 |
考试答题明细表（exam_answer）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| paper_id | bigint | 关联试卷表 |
| question_id | bigint | 关联试题表 |
| user_answer | varchar(10) | 考生答案 |
| is_correct | int | 0=错，1=对 |
错题表（wrong_question）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| user_id | bigint | 考生ID |
| question_id | bigint | 试题ID |
| wrong_answer | varchar(10) | 错误答案 |
| create_time | datetime | 加入时间 |
3.2 表关系设计的关键考量
这六张表的关联关系是：sys_user与exam_paper一对多；exam_paper与exam_answer一对多；question与rule_category多对一；sys_user与wrong_question一对多；question与wrong_question一对多。
有几个细节值得说一下。exam_answer为什么要单独一张表而不是在exam_paper里搞一个JSON字段存所有答案？因为分开存储后，成绩统计、错题分析、每道题的正确率计算都变得非常简单，你只需要关联查询加聚合函数就能得出结果。另外，在exam_paper表里保留total_questions、total_score、pass_score这些字段也很关键——这些是“考试规则”的冗余存储，因为如果考试规则后续被管理员修改了，历史试卷的记录仍需要保持创建时的快照，这是从业务合理性角度的设计考量。
还有一个小技巧：wrong_question表加了一个wrong_answer字段，而不是只存question_id。这能记录你当时到底选了哪个错误选项，在错题本展示时就能一句“上次你错选了B”点醒考生，比单纯显示原题有用得多。
4. 后端SSM框架实现的核心细节
4.1 三层架构下的工程目录规划
后端工程用Maven搭建，包结构我强烈建议按下面的方式组织，既符合规范又方便论文里画架构图：
com.xxx.jiaotong ├── controller // 表现层，接收前端请求 │ ├── UserController │ ├── QuestionController │ ├── ExamController │ └── CategoryController ├── service // 业务层接口 │ └── impl // 业务层实现 ├── mapper // 持久层接口（MyBatis的Mapper） ├── entity // 实体类 ├── common // 通用类：Result响应封装、分页工具等 ├── config // 配置类：拦截器、跨域配置 └── util // 工具类：JWT工具、密码加密工具Controller层只做三件事：接收参数、调用Service、返回Result对象。Service层只做业务逻辑，并在需要事务操作的地方加@Transactional注解。Mapper层通过接口方法与XML里的SQL语句对应，保持数据库操作的集中管理。
4.2 SSM常用注解的实战用法
既然题目里出现了“SSM常用注解”这个热词，我就把项目里真正会用到的注解盘点一遍，说清楚每个注解用在哪里、为什么这么用。
@Controller 与 @RestController：在Controller类上标注。考试系统里的接口全部返回JSON，所以直接统一用@RestController，它相当于@Controller + @ResponseBody，不用每个方法都单独写响应体注解。
@RequestMapping 及其变体：类级别用@RequestMapping("/api/question")定义模块前缀，方法级别用@GetMapping、@PostMapping、@PutMapping、@DeleteMapping来区分HTTP操作。这里有个我踩过的坑：RESTful风格下不要一个类里既写@GetMapping又写@RequestMapping(method = RequestMethod.GET)，混用的结果是代码可读性极差，后面想加个Swagger文档都会费劲。
@Autowired：Spring的依赖注入注解，标注在Service和Mapper字段上。现在也有人推荐构造器注入，但SSM项目的传统风格就是字段注入，毕设答辩一般不会在这个细节上深究。需要注意的是，如果你在Web项目里使用了@Autowired但依赖没有对应的Bean，启动会直接报错，所以字段名要和Bean名称保持一致，不要随手改名。
@Transactional：加在Service实现类上。考试系统的核心金融级操作（虽然不涉及真实资金）是“提交试卷”这个方法：既要计算得分、更新试卷状态，还要插入答题明细、判断并写入错题本。这四个操作如果不在同一事务里，就会出现“分数算出来了但错题没记录”这类数据不一致的问题。所以这个场景加了类级别的@Transactional(rollbackFor = Exception.class)。
@PathVariable 与 @RequestBody：前者用于从URL路径中获取参数，比如@GetMapping("/question/{id}")；后者用于接收前端传来的JSON对象。SpringMVC的JSON序列化默认依赖Jackson，实体类的字段命名规范与否直接决定了传输是否顺畅。我在项目里就用了个带下划线的字段名，结果前端拿到的是create_time而不是createTime，整整排查了一个小时才发现，这就是实体类字段没和数据库字段对齐带来的坑。所以你建实体类时，建议字段名统一使用驼峰命名，并在MyBatis配置里开启mapUnderscoreToCamelCase自动映射。
4.3 Service层业务逻辑的编排
业务层是整个系统的核心，我认为有两个方法的实现最能体现技术水平。
第一个是“随机组卷”。这个功能的SQL其实不复杂：
-- 从题库中随机抽取指定数量的单选题 SELECT * FROM question WHERE category_id = #{categoryId} AND question_type = 2 ORDER BY RAND() LIMIT #{count};但专业的地方在于业务逻辑的编排——你需要根据管理端配置的规则，逐个分类按配额抽取题目，然后把它们组装成一个试卷对象。这里千万不要在Service里写一堆硬编码的for循环加if，更合适的做法是写一个PaperGenerator组件，输入是一个ExamRule对象（包含各分类题目数量），输出是一张试卷。这样代码的复用性很强，以后想加“按难度出题”或“按知识点出题”，只需要扩展规则对象而不动组卷引擎。
第二个是“自动评分并记录错题”。这个方法里前半段是标准操作：遍历答题明细，比对正确答案，累加得分，更新试卷状态。后半段就是体现细节的地方了——答错的同时写入错题表。需要注意的坑是，如果考生重复错同一道题，错题表里会积累多条重复记录。我的解决方法是先查该用户错题表里是否已有这一题，有了就更新wrong_answer和create_time，没有才新增。这个“存在即更新”的策略让错题本始终保持每道题一条最新记录，展示起来很清爽。
4.4 MyBatis的XML写法与动态SQL
MyBatis是SSM里最需要细心的一环。我的Mapper接口与XML文件放在同包同路径下，SQL的高级用法主要体现在动态SQL上。
列表查询用<if>做多条件组合筛选：
<select id="selectQuestionList" resultType="com.xxx.entity.Question"> SELECT * FROM question <where> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="questionType != null"> AND question_type = #{questionType} </if> <if test="content != null and content != ''"> AND question_content LIKE CONCAT('%', #{content}, '%') </if> </where> ORDER BY id DESC </select>写动态SQL时，我最常犯的错误是忘记加<where>标签而是直接写WHERE 1=1。虽然WHERE 1=1在功能上没问题，但它不是一个好的SQL习惯——因为它会打破索引优化，而且看起来不专业。用<where>标签能自动去掉第一个多余的AND，规范又安全。
批量插入用<foreach>：
<insert id="batchInsert"> INSERT INTO question (category_id, question_type, question_content, option_a, option_b, option_c, option_d, correct_answer, analysis) VALUES <foreach collection="list" item="item" separator=","> (#{item.categoryId}, #{item.questionType}, #{item.questionContent}, #{item.optionA}, #{item.optionB}, #{item.optionC}, #{item.optionD}, #{item.correctAnswer}, #{item.analysis}) </foreach> </insert>批量导入Excel里的题目时，一次性batchInsert几百条数据，比在Java里循环调用单条insert快了不止一个量级，这个优化点也可以写进论文的“系统优化”章节。
5. 前端Vue部分的设计与实现要点
5.1 Vue工程化搭建与路由配置
前端我用Vue CLI搭建工程，这里可以聊一下新手最容易卡住的“vue安装及环境配置”问题。我的建议是：Node.js版本选LTS（长期支持版），不要追新版本；Vue CLI装3.x以上；创建项目时勾选Router、Vuex、Eslint这几个插件，一步到位，比手动加依赖省心得多。
路由配置上，考试系统的页面结构不复杂，可以用一个模块化的思路来做：
const routes = [ { path: '/', component: Layout, redirect: '/home', children: [ { path: 'home', name: 'Home', component: Home }, { path: 'exam', name: 'Exam', component: Exam, meta: { requiresAuth: true } }, { path: 'practice', name: 'Practice', component: Practice, meta: { requiresAuth: true } }, { path: 'wrong', name: 'WrongQuestion', component: WrongQuestion, meta: { requiresAuth: true } }, { path: 'scores', name: 'ScoreHistory', component: ScoreHistory, meta: { requiresAuth: true } } ] }, { path: '/login', name: 'Login', component: Login }, { path: '/admin', component: AdminLayout, meta: { requiresAdmin: true } } ];路由守卫我用的是beforeEach钩子，作用是判断用户是否登录、是否有权限（管理员页面需要验证角色）。这里有一个实战细节：Vue Router 4（对应Vue 3）的路由写法与Vue Router 3（对应Vue 2）有差异，尤其是createRouter和createWebHistory的问题。如果你用的是Vue 2.x，请一定装vue-router@3，装@4版本会直接报各种奇奇怪怪的错误。这就是为什么我一再强调版本匹配的问题——这种环境问题在毕设答辩前突然出现，真的能把人急疯。
5.2 Axios的统一封装与跨域处理
前后端分离最让人头疼的永远是请求和跨域。我的做法是单独建一个request.js文件统一封装Axios：
import axios from 'axios'; import { Message } from 'element-ui'; import router from '../router'; const service = axios.create({ baseURL: process.env.VUE_APP_BASE_URL || '/api', timeout: 10000 }); // 请求拦截器：加 token service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); // 响应拦截器：统一处理错误 service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { Message.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res; }, error => { Message.error(error.response?.data?.message || '网络异常'); return Promise.reject(error); } ); export default service;这个封装解决了三个问题：不用在每个组件里重复写axios.get配置、登录状态统一通过拦截器挂载、错误提示统一用Element UI的Message组件弹出。跨域问题在后端配置，加一个CorsFilter过滤器即可，不需要前端去处理。很多新手在代理服务器上反复折腾跨域，其实与其在前端配置proxy后还要在部署环境里精调，不如直接在后端开启全局限流跨域，代码量少，效果直接。
5.3 考试页面的核心交互实现
考试页面是整个前端最复杂的部分，也是答辩时最容易出彩的地方。我把它拆成几个核心组件：
- 答题卡组件：右侧显示所有题目序号，已答的用绿色高亮、未答的用灰色、当前题用蓝色边框。点击序号可以快速跳转。这个组件的核心是用一个数组维护每道题的作答状态，通过计算属性动态绑定样式类。
- 计时器组件：显示剩余时间，用
setInterval每秒更新。到0秒时自动调用提交接口。要注意页面离开时需要清理定时器，否则会造成内存泄漏。 - 题目展示组件：包含题干、四个选项（判断题是“对/错”两个选项）。选项用 v-for 渲染，绑定点击事件设置答案。
- 交卷确认弹窗：交卷前弹出确认框，显示“已答XX题，未答XX题”，确认后才真正提交。
下一题的行为逻辑是这样的：
methods: { nextQuestion() { if (this.currentIndex < this.totalQuestions - 1) { this.currentIndex++; } }, submitExam() { this.$confirm('确定要交卷吗？', '提示', { type: 'warning' }) .then(() => { this.finish(); }); }, finish() { clearInterval(this.timer); const answers = this.questionList.map((item, index) => ({ paperId: this.paperId, questionId: item.id, userAnswer: this.answers[index] })); axios.post('/api/exam/submit', { paperId: this.paperId, answers: answers }).then(res => { this.$router.push({ path: '/result', query: { score: res.data.score } }); }); } }这里有一个容易忽略的点：考试中途如果用户刷新了页面，正在进行的考试状态就会丢失。我当时的场景是在created钩子里检查paperId是否存在，存在则调用“恢复考试”接口，从后端把该用户未交卷的草稿拉回来。这个“断点续考”功能听起来不大，但写到论文里是一个很好的创新点——它需要后端为试卷的暂存状态专门设计一张草稿表或者利用现有字段加一个status=0的查询接口。
6. 前后端联调、打包部署的实战记录
6.1 联调阶段最容易忽视的接口规范问题
前后端分离最怕的就是“前端和后端对不上接口”。我建议在正式开发前，先把所有接口路径、请求方式、参数名、返回结构定义成一张接口文档表格。后端返回统一用{ code: 200, message: 'success', data: {...} }的结构，前端在request.js里统一解析这个格式。这样联调时基本不会出现“我传的是categoryId你接收的是category_id”这种低级错误。
一个实际经验是：开发阶段可以把后端接口的Swagger打开，前端直接照着Swagger页面里的参数调试，比翻文档高效得多。SSM整合Swagger需要配一个配置类，SpringMVC的路径匹配规则偶有冲突，注意看启动日志提示进行路径调整。
6.2 Vue打包后放进SSM工程的部署方式
部署这部分我要重点讲讲，因为这是“vue打包放进springboot中”这个热词对应的实战场景，但SSM的原理也类似。
开发阶段，前端用npm run serve启动开发服务器（默认8080端口），后端在IDEA里跑Tomcat（默认8080），前端访问接口时通过Vue CLI的proxy代理转发解决跨域：
// vue.config.js module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };到了演示阶段，就不需要两个服务同时跑了。把Vue项目构建后的dist目录直接复制到SSM工程的webapp目录下，Tomcat启动后就能同时提供前端静态资源和后端API。这样一来，答辩老师只需要双击启动Tomcat这一个动作，就能看到完整系统，这比既启动前端又启动后端的演示过程稳太多了。
需要注意的是，SSM项目的web.xml中SpringMVC的前端控制器DispatcherServlet默认拦截所有请求（url-pattern为/），所以dist目录下的静态资源会被SpringMVC接管。这种情况下需要确认SpringMVC的配置了<mvc:resources>来支持静态资源映射，否则页面能打开但CSS和JS全部加载不出。
6.3 从开发到演示的环境准备清单
我把这次项目从开发到演示的环境配置整理成一个清单，照着做基本不会出问题：
- JDK 1.8（SSM项目用8最稳，13以上的版本配Tomcat 9可能会有兼容问题）
- Maven 3.6+，配置好阿里云镜像，不然下载依赖能等到怀疑人生
- Tomcat 8.5（对应JDK 1.8的Servlet 3.1规范）
- MySQL 5.7（8.0的驱动包要换，需要留意连接串参数）
- Node.js 14 LTS（Vue 2项目在这个版本上最舒服）
- IDEA装好Lombok插件（实体类用
@Data注解能少写几十行getter/setter）
这个清单看起来简单，但“环境变量配没配好”“Maven仓库路径有没有手动改成非C盘位置”这些细节，每届毕设都能放倒一批人。我自己的经验是：先把MySQL和Tomcat配好再碰代码，环境基线干净了，后面排错才能快速定位。
7. 常见问题排查与避坑实录
7.1 后端高频报错与定位思路
报错一：Tomcat启动时端口被占用。这个太经典了，八成是之前启动的Tomcat没关干净，或者IDEA里热部署的残留进程还在。排查口诀是：先netstat -ano | findstr 8080，根据PID到任务管理器杀掉对应进程，再重新启动。
报错二：MyBatis绑定异常，提示Invalid bound statement (not found)。出现这个错误，先检查三件事：Mapper接口和XML文件是否同包同名、XML文件里的namespace是否和接口全限定名一致、IDEA编译时有没有把resources目录下的XML文件拷贝到classes目录。最后这个是新手最容易忽略的，需要在pom.xml里为src/main/java下的XML指定资源编译，否则写接口包里的XML文件根本不会进入最终产物。
报错三：注入失败，No qualifying bean of type。原因通常是Service实现类没有加@Service注解，或者标注了但类名与接口名不一致导致扫描不到。还有一个隐蔽场景是Spring配置里component-scan的包路径写错了。排查方法是在配置类上开DEBUG日志，看启动时到底扫描到了哪些Bean。
报错四：前后端数据交互时出现HttpMessageNotReadableException。九成是因为前端JSON里的字段与后端实体类对不上。比如前端传questionType，后端实体类的字段是question_type，如果配置了驼峰映射则没事，否则就是这里崩的。建议联调时先在浏览器F12看Network面板里实际发送的请求体结构，再对照后端实体类字段检查。
7.2 前端常见问题与排查技巧
问题一：路由跳转后页面空白。这多半是路由配置错误，比如component没有正确导入组件。还有一个很现实的原因：路径大小写不一致。Linux服务器上部署时路径区分大小写，Windows上不区分，所以本地能跑但发到服务器上就白屏，这种事我见得太多了。
问题二：接口请求成功但页面数据没刷新。确认后端返回的JSON结构是否与预期一致。比如你写的是res.data.data.list，但后端返回的是res.data.data.records，取不到值就会一直空白。一个补救办法是在request.js拦截器里对返回的数据结构统一console.log打印一次，联调阶段开着控制台看，问题基本能现场发现。
问题三：Element UI组件样式没有生效。检查项目里是否按需引入了组件样式，是否引入了element-ui/lib/theme-chalk/index.css。很多新手只引入了组件库却忘了引样式，导致页面上一堆裸标签。
问题四：在Vue中播放m3u8视频。这个是热词引申出来的场景。交规系统的题库偶尔会涉及交通监控视频类题目，可以实现在线播放视频片段再答题。如果毕设想加入视频题，HTML5的video标签默认不支持HLS流，需要引入hls.js或video.js，在mounted里初始化播放器实例。不过这个复杂度比较高，建议只有题目要求完整覆盖视频题型时才考虑加。
7.3 论文写作与程序配合的实操经验
毕设是“论文+程序”的组合，很多人的误区是把论文当成程序的说明书往后抄，结果论文写得像API文档。我建议论文和技术实现采用“两条腿走路”的策略：
程序是论文学术观点的验证载体，论文是程序业务逻辑的抽象表达。论文里写“本系统采用三层架构，实现了表现层与业务逻辑层的解耦”，代码里就要有清晰的Controller-Service-Mapper分层来支撑这个说法；论文里写“系统设计了自动组卷算法，提高了考试评价的随机性与公平性”，程序里就该有那个PaperGenerator的组件来演示这个算法。
内容安排上，我的建议是论文的技术部分花大篇幅在后端设计上，特别是数据库ER图、接口设计的表、以及自动组卷和评分判分这两个核心业务函数的伪代码与流程图。前端部分重点写清楚Vue组件化结构、路由设计和状态管理方案，配合几个核心页面的截图就足够有说服力。
还有一个想象不到的加分项：论文里的“系统测试”章节，一定要有测试表格——测试用例（正常流程、异常流程）、预期结果、实际结果、是否通过，这个表格一旦把每个模块的测试记录填满，答辩老师翻到这一页就会觉得你做事很扎实。
另外，PPT答辩演示的时候，建议提前准备几组演示数据：一个题库里至少塞50~100道题，三个测试账号，成绩统计里有几条不同的错误记录，这样现场演示随机组卷、错题生成、成绩图表时才有数据支撑。空数据库演示是最尴尬的，容易让人怀疑系统没有经过真实测试。
7.4 从零到答辩通过的全流程时间线
最后给你一个可参考的时间分配。整个项目如果每天投入2~3小时，六个星期完全可以走完：
- 第一周：搭环境、建库建表、完成用户注册登录和角色权限
- 第二周：完成后端题库管理接口、分类管理、用户管理接口
- 第三周：完成练习模块接口、考试组卷评分核心逻辑、错题接口
- 第四周：前端页面（登录页、首页布局、管理端页面）
- 第五周：前端核心页面（考试页、答题卡、成绩页、错题本）+ 联调
- 第六周：写论文、整理测试数据、录制演示视频、准备答辩PPT
如果你时间紧，我的建议是优先保证“完整跑通”，其次再考虑优化和炫技。一个能演示完整个业务流程的系统，比一个有十个创新点但演示时卡壳的系统，拿到的分数只会更高。
实际项目做下来，我对SSM这套老架构反而多了一些好感：它的代码清晰透明，每一条SQL都在你的掌控之中，不像那些过度封装的企业框架，出了问题翻半天源码也定位不到。做毕设的价值不在于用多新的技术，而在于你能否把一个完整的业务闭环从头到尾跑通，并讲清楚每一个环节为什么这么设计、有没有更优的替代方案。这套交规考试系统做完，你既熟悉了Java后端三大框架的协作方式，也体会了Vue组件化开发的感觉，答辩时无论老师怎么追问，你都有真实可谈的底气。
