作为一个写过不少SSM+Vue项目的老手，我今年接到的毕设咨询里，错题管理系统出现的频率相当高。仔细想想并不奇怪——这个选题技术栈主流、业务逻辑清晰、功能扩展空间大，既能展示后端架构能力又能体现前端交互水平，而且数据可视化部分天然适合做论文亮点。今天这篇就把这套系统的完整实现思路拆开来讲，从数据库设计到后端核心接口，从前端页面结构到论文写法，包括开发过程中那些不写进教程里的坑，一次性说透。无论你是打算拿这个题目做毕设，还是单纯想学SSM+Vue的前后端分离开发，这篇文章都值得认真读一遍。

1. 为什么错题管理系统会出现在这么多毕设选题里

1.1 需求端：错题管理真是个被验证过的刚需

先说个很现实的问题：为什么偏偏是错题管理系统而不是别的什么系统？我做过的教育类项目里，错题本这个需求几乎每个阶段都存在。小学阶段家长帮忙整理错题，中学阶段学生手动抄写，到了大学阶段各种考证刷题，错题的沉淀和复盘需求一直很强烈。但手动抄写效率太低，拍个照存在手机里又没法做分类统计，市面上的专业应用不是收费就是收录范围跟教材不匹配。自研一套系统的空间就在这里——基础功能扎实，需求覆盖面广，用户画像清晰，演示效果直观。

这类系统的核心场景可以归成三个维度：录入与归档、分类与检索、复习与统计。录入解决的是“错题怎么进来”的问题，包括手动输入、批量导入、图片上传；分类解决的是“错题怎么组织”的问题，按科目、知识点、错误原因、难易程度做多层标签；复习和统计解决的是“错题怎么用”的问题，包括回顾时间提醒、掌握程度跟踪、正确率趋势统计。三个维度环环相扣，恰好对应了从数据采集到数据消费的完整链路。

1.2 选题端：这个体量刚好卡在毕设的舒适区

毕设选题最怕什么？怕需求太复杂做不完，更怕需求太简单没东西写。错题管理系统的好处在于，它的业务复杂度处于一个很理想的位置：

• 领域模型清晰：用户、科目、错题、知识点、复习记录，主实体之间的关系一目了然，做ER图不费力。
• 功能边界可控：核心功能是一套CRUD加统计分析，再加上用户体系和权限控制，工作量可控。
• 技术展示面全：既能体现SSM后端的框架分层能力，又能展示Vue前端的组件化开发水平，数据库设计部分也有足够的表结构能写。

同类项目里，学生管理系统太教科书气，电商系统又容易陷进订单、库存、支付这种伤筋动骨的业务细节，二手交易平台一旦涉及商品图片存储和推荐逻辑复杂度就失控。错题管理系统属于那种“看起来不算大，但每个模块都能讲出设计思路”的题目，对写论文来说素材充足，对答辩来说演示逻辑完整，确实是进退都比较从容的选择。

2. SSM+Vue这套组合的前世今生与选型理由

2.1 SSM框架层：Spring管对象、SpringMVC管请求、MyBatis管数据

说到SSM，很多同学第一反应是“框架太老了”，但这里要理解为什么老组合依然能打。Spring的核心价值是IoC（控制反转）和AOP（面向切面编程），IoC让对象之间的依赖关系从代码里挪到容器里管理，写接口的时候只需要声明依赖，不用自己new对象，这大幅降低了模块之间的耦合度。SpringMVC负责HTTP层的请求分发，通过DispatcherServlet把用户的URL请求映射到具体的Controller方法，配合注解开发，一个方法就是一个接口，开发效率非常高。MyBatis则是半自动ORM框架，SQL语句由开发者手动编写，在复杂查询场景下有完全的控制力，同时通过Mapper接口与XML映射文件的方式，把数据访问逻辑隔离出来。

这个组合虽然不像Spring Boot那样能用自动配置快速起项目，但它的优势恰恰在于“显式”和“透明”。配置文件、注解、XML映射全部摆在你面前，每一层干了什么一眼能看明白，这对毕设答辩来说反而是好事——面试官或答辩老师追问细节的时候，你能讲得具体，而不是甩一句“框架帮我做好了”。

SSM下的项目结构一般是标准的三层分包：

com.example.wrongbook ├── controller // 接收请求、返回视图或JSON ├── service // 业务逻辑层，处理事务 ├── mapper // MyBatis的Mapper接口 ├── pojo // 实体类（User, WrongQuestion, Subject...） ├── common // 通用类（返回结果封装、分页对象等） └── config // Spring、SpringMVC配置

2.2 Vue层：为什么选Vue而不是别的

前后端分离的大背景下，前端从JSP时代升级为单页应用（SPA）架构。选Vue的原因很实际：上手曲线平缓，中文文档完善，社区方案成熟，而且Vue的响应式数据绑定和组件化开发，恰好契合管理后台这类以表单和列表为主要交互形态的系统。

在错题管理系统里，Vue承担的核心工作有三个：

• 组件化：把页面拆成头部导航、侧边栏、错题卡片、统计图表、表单弹窗等独立组件，复用性和可维护性都更好。
• 状态管理：登录状态、用户信息、筛选条件、当前科目这类全局数据放进Vuex统一管理，页面之间共享数据不再需要通过路由参数传来传去。
• 数据交互：通过axios发送异步请求，拿到后端返回的JSON数据后绑定到页面上，实现无刷新更新。

前端目录结构大致是：

vue-wrongbook ├── src │ ├── api // axios请求封装 │ ├── components // 通用组件 │ ├── router // 路由配置 │ ├── store // Vuex状态管理 │ ├── views // 页面视图 │ │ ├── Login.vue │ │ ├── Dashboard.vue │ │ ├── WrongQuestionList.vue │ │ ├── WrongQuestionEdit.vue │ │ ├── Statistics.vue │ │ └── KnowledgePoint.vue │ ├── utils // 工具函数 │ └── main.js

2.3 前后端分离的接口约定

SSM后端返回JSON，Vue前端消费JSON，中间的桥梁就是RESTful接口。这里要提前定义好统一的返回格式，不然联调的时候会非常痛苦的。

我习惯用一个统一的Result对象封装返回值：

public class Result<T> { private Integer code; // 状态码，200表示成功，500表示失败 private String message; // 提示信息 private T data; // 业务数据 }

这样前端就不需要针对每个接口单独判断数据结构，axios封装里统一拦截，方便处理超时、token失效、服务器异常等情况。

3. 数据库设计：把错题的三个核心维度拆清楚

3.1 从业务反推实体，列清主表与关联表

做数据库设计时别上来就画表，应该从用户的使用路径开始推演。一个学生用户登录系统后需要做什么？按科目浏览错题、选择某个知识点查看错因分布、标记某道题已经掌握、查看近期的正确率曲线。顺着这条路径反向拆解，核心实体其实就五张：

• 用户表（user）：存账号密码和基础信息，角色字段用于区分学生和管理员权限。
• 科目表（subject）：常见科目如语文、数学、英语、物理、化学，允许用户自定义。
• 错题表（wrong_question）：这是核心业务表，存题干、选项、正确答案、用户答案、错误原因、难易程度、掌握状态等。
• 知识点表（knowledge_point）：每个科目下可以挂多个知识点，便于按点复习。
• 复习记录表（review_record）：每次复习操作留痕，用于统计复习次数、遗忘曲线相关数据。

五张表之间还有两个关联关系不能省：错题与知识点是多对多关系（一道错题可能同时涉及多个知识点），错题与科目是多对一关系。多对多关系在物理实现上需要一张中间表，我用的是错题知识点关联表（question_knowledge）来承接。

3.2 核心表的字段设计：看似简单，其实全是细节

错题表是整个系统的重头戏，字段设计直接影响后续所有功能的实现难度。下面是我整理的一份参考结构：

CREATE TABLE wrong_question ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL COMMENT '所属用户ID', subject_id INT NOT NULL COMMENT '科目ID', question_type VARCHAR(20) DEFAULT 'choice' COMMENT '题型：choice判断/fill填空/essay主观', content TEXT NOT NULL COMMENT '题干内容', options TEXT COMMENT '选项，JSON格式存储', correct_answer TEXT COMMENT '正确答案', user_answer TEXT COMMENT '用户的错误答案', mistake_reason VARCHAR(255) COMMENT '错误原因分类', difficulty TINYINT DEFAULT 3 COMMENT '难易度 1-5', source VARCHAR(100) COMMENT '来源，如xx试卷/xx练习册', mastery_status TINYINT DEFAULT 0 COMMENT '掌握状态 0未掌握 1已掌握 2需巩固', review_count INT DEFAULT 0 COMMENT '复习次数', last_review_time DATETIME COMMENT '上次复习时间', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT '错题表';

这里有几个字段是后来实际开发才发现的“隐藏需求”。options用JSON格式存储，是因为选择题选项数量不固定，有的题3个选项有的题5个选项，用单独字段存options_a、options_b这种设计完全是在给自己挖坑。mistake_reason不用自由文本，而是用预定义分类，是因为统计时要按原因聚合，自由文本根本没法聚合。mastery_status是复习闭环里最关键的一个字段，它本质上是一个状态机，从“未掌握”到“需巩固”再到“已掌握”，每次复习都可能改变状态。

3.3 索引设计与数据查询的联动

数据量不大的时候索引可以不用太在意，但如果演示时要统计年度正确率、按科目筛选错题列表，索引的作用还是很明显的。主键id自动有索引，这个是基础的。user_id必须有索引，因为所有查询都带着用户Id做隔离。subject_id和mastery_status组成联合索引，能覆盖“按科目查看未掌握错题”这种高频查询场景。last_review_time加索引是给“需要复习的错题列表”服务，查询最近7天未复习的错题时扫描范围能大幅减小。

关于表字段类型，有几个容易踩的坑：

• 题干用TEXT而不是VARCHAR，因为有些简答题题干很长，VARCHAR(255)根本不够。
• 时间字段统一用DATETIME，别用TIMESTAMP，虽然两者可以互相转换，但TIMESTAMP存储范围只到2038年，虽然系统演示不受影响，但是论文里表述上DATETIME更规范。
• 状态类字段（如mastery_status、difficulty）用TINYINT，占一个字节就够了，同时每张表都保留create_time和update_time，后面做时间维度统计分析会非常顺手。

4. 后端核心实现：从Controller到SQL的完整链路

4.1 Controller层：接口设计先定下来，联调才不慌

后端开发的第一步不是写代码，而是先定义好接口列表。错题管理系统的接口拆成以下五大模块：

Controller层的代码模式很固定，接收参数、调用Service、返回Result。

@RestController @RequestMapping("/api/question") public class WrongQuestionController { @Autowired private WrongQuestionService wrongQuestionService; @GetMapping("/page") public Result<PageResult<WrongQuestionVO>> getQuestionPage(@RequestParam Integer pageNum, @RequestParam Integer pageSize, @RequestParam(required = false) Integer subjectId, @RequestParam(required = false) Integer masteryStatus, @RequestParam(required = false) String keyword) { return Result.success(wrongQuestionService.queryQuestionPage(pageNum, pageSize, subjectId, masteryStatus, keyword)); } }

4.2 Service层：事务边界为什么要这样划

Service层的核心价值是业务逻辑组织和事务控制。错题新增接口的事务边界就值得思考：插入错题表的同时要建立错题与知识点的关联关系，这两个操作必须在一个事务里，否则出现一个问题——错题写了但知识点关联没写进去，复习时按知识点筛不出来，数据就不一致了。

代码上是这样控制的：

@Service public class WrongQuestionServiceImpl implements WrongQuestionService { @Transactional public void addWrongQuestion(WrongQuestionDTO dto) { // 校验用户ID、科目ID是否合法 // 插入错题表，拿到自增主键questionId // 遍历知识点ID列表，逐条插入question_knowledge中间表 // 更新科目统计信息（错题总数+1） } }

事务不是越多越好。查询操作千万别加@Transactional，那是没必要的开销。只有“写多张表、数据一致性要求高”的操作才需要事务。另外如果一个方法内部调用同一个类里的另一个@Transactional方法，事务是不生效的，因为Spring事务是基于代理对象的，内部调用走的是原对象而不是代理，这个机制很多同学第一次接触时都会踩到。

4.3 Mapper层：MyBatis动态SQL是筛选功能的灵魂

错题列表的多条件筛选是系统里最复杂的一个查询。科目、掌握状态、错误原因、时间范围、关键字搜索，每个条件都可选可不选，这种情况用固定SQL写起来就是噩梦，而MyBatis的动态SQL恰好是解决这个问题的钥匙。

<select id="selectQuestionPage" resultType="com.example.wrongbook.pojo.WrongQuestionVO"> SELECT wq.*, s.subject_name, GROUP_CONCAT(kp.knowledge_name) AS knowledge_names FROM wrong_question wq LEFT JOIN subject s ON wq.subject_id = s.id LEFT JOIN question_knowledge qk ON wq.id = qk.question_id LEFT JOIN knowledge_point kp ON qk.knowledge_id = kp.id <where> wq.user_id = #{userId} <if test="subjectId != null and subjectId != ''"> AND wq.subject_id = #{subjectId} </if> <if test="masteryStatus != null"> AND wq.mastery_status = #{masteryStatus} </if> <if test="mistakeReason != null and mistakeReason != ''"> AND wq.mistake_reason = #{mistakeReason} </if> <if test="keyword != null and keyword != ''"> AND (wq.content LIKE CONCAT('%', #{keyword}, '%') OR wq.source LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="startTime != null"> AND wq.create_time &gt;= #{startTime} </if> </where> GROUP BY wq.id ORDER BY wq.create_time DESC LIMIT #{offset}, #{limit} </select>

这里三个点值得展开说。第一是GROUP BY wq.id配合GROUP_CONCAT，作用是把多对多的知识点名称聚合成一个字段返回，前端直接展示“一元二次方程、韦达定理”这样的字符串，不需要再发第二次请求。第二是<where>标签的妙处，它会自动处理“第一个条件前要不要加AND”的问题，如果所有条件都为空，生成的SQL就直接没有WHERE子句。第三是模糊查询的写法建议用LIKE CONCAT('%', #{keyword}, '%')，别用'%${keyword}%'拼接，后者有SQL注入风险，写进论文的时候这恰好能成为加分细节。

4.4 登录认证与权限控制的轻量实现

SSM+Vue的项目没法直接引入Spring Security那套重武器（当然也可以引入，但配置复杂度会让毕设进度失控），我用的是一种轻量级的JWT拦截器方案。用户登录成功后，后端用JWT工具类生成一个包含用户ID和有效期的token，返回给前端存储。前端每次请求在axios拦截器中带上Authorization头部，后端通过拦截器验证token里的用户ID，放到Request作用域里供后续SQL查询使用。

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); // 解析token，校验有效期和用户ID // 把用户ID存入request Scope，后续Controller可以获取 return true; } }

权限方面毕设不需要做太复杂的RBAC模型，给user表加一个role字段就行，学生角色只能操作自己的数据，管理员角色可以查看系统里所有错题的统计信息。课堂教学和项目里的对比挺有意思，用Spring Security反而要写大量配置，而这个方案核心逻辑不超过一百行，应用层的问题用应用层的方案解决，不要在毕设里制造架构复杂度。

5. 前端Vue页面：从登录到错题统计的状态管理

5.1 路由与鉴权：登录状态要守住，刷新不丢

Vue项目启动后第一件事是配路由和判断登录状态。我用vue-router的全局前置守卫做登录拦截，核心逻辑是一个判断：如果路由需要鉴权且本地没有token，就强制跳到登录页；如果已登录但访问登录页，就跳回首页。

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

token放在localStorage还是Vuex里，这个选择很多人会纠结。我的建议是两者配合：localStorage负责持久化，Vuex负责运行时读取。刷新页面时从localStorage同步一次用户信息到Vuex，这样刷新后页面状态不丢，全局组件的用户头像、昵称显示都正常。

5.2 错题录入页：表单组件化与图片上传的处理

错题录入页是系统使用频率最高的页面，交互设计要尽量降低录入成本。表单字段包括题干、选项、正确答案、用户答案、错误原因、科目、知识点、来源、难易程度。题型切换逻辑要处理好：选“选择题”才显示选项编辑区；选“填空题”隐藏选项区；选“主观题”则隐藏用户答案区并增加题干图片上传。

图片上传这个点很多毕设不做，但做了就是加分项。流程是前端用el-upload组件选图，调后端的图片上传接口，后端把文件保存到服务器磁盘并返回访问URL，URL随之存入错题表的一个图片字段。配置虚拟路径映射时有个细节很容易踩坑，上传目录如果在WEB-INF下就访问不到，要么在web.xml配置外部目录映射，要么用类似/upload/**映射到本地磁盘目录。这个坑在联调阶段几乎必然出现，建议提前搞定。

5.3 错题列表页：筛选区与卡片列表的联动逻辑

列表页是整个系统的核心操作界面。左侧筛选栏有科目下拉、掌握状态下拉、错误原因下拉，右侧是错题卡片。筛选条件变化就触发重新查询，数据加载时加loading状态防止用户重复点击。这里我强烈建议用懒加载的分页形式，打开页面只加载第一页（默认20条），滚动到底部再加载下一页，避免一次查询全量数据的性能压力。

每个错题卡片上展示题干摘要、科目标签、知识点标签、掌握状态标识，底部有三个操作按钮：复习（点击后弹窗确认是否掌握）、编辑、删除。复习按钮的实现逻辑调后端的/api/review/add接口，传入错题ID和本次掌握状态（掌握了/还需复习），后端更新错题表的review_count和mastery_status，前端收到响应后把卡片状态重新渲染或直接移除。

组件之间的通信这里要强调一下：错题列表页和编辑弹窗是两个组件，编辑完成回传数据的方式最好用$emit事件通知父组件刷新列表，而不是让编辑组件的props绑定一个会被直接修改的对象——这个反模式在Vue里非常常见，但很容易导致数据更新不同步。

5.4 统计页：ECharts图表的接入与数据格式转换

统计页面的价值在于让“错题”变成“数据资产”。我接入的是ECharts，图表类型选两种就够了：各科目错题数占比用的饼图，每月错题量或正确率趋势用的折线图。

后端返回的数据是标准结构，前端需要做一步数据转换：

// 后端返回 [{subjectName: '数学', count: 34}, {subjectName: '英语', count: 56}] const pieData = response.data.map(item => ({ name: item.subjectName, value: item.count }));

ECharts的响应式容器有个问题要知道：图表容器初始化时必须有固定高度，不然图表渲染空白。在Vue组件里，mounted阶段初始化图表，watch到筛选条件变化时更新图表数据，离开页面时调用dispose销毁图表释放内存。这个完整闭环在课堂项目里基本不讲，但实际开发中每个环节都可能出问题。

6. 毕业论文的章节结构：从开题到答辩的写作思路

6.1 论文的整体章节安排：按软件工程标准范式走

毕业论文不同于技术博客，它需要体现工程方法的完整性。标准的软件工程范式是最稳妥的结构，我校是下面这个章节安排（其他高校的论文要求大同小异）：

6.2 需求分析与功能模块划分：用例图怎么画才不空泛

画用例图的第一步不是画图，而是列出参与者。这个系统有两个参与者：学生用户（核心参与者）和系统管理员（辅助参与者）。学生用户的用例包括账号注册登录、错题录入、错题修改删除、错题查询筛选、知识点管理、错题复习、复习统计查看；管理员用户的用例包括用户管理、科目管理、系统数据统计查看。用例图不是越多越好，要让每个用例都能对应到后端的某个接口和数据库的某张表，这样答辩被问到“这个功能怎么实现”时才能对答如流。

6.3 系统设计章节里的数据库ER图

画ER图时不要犯实体多到图都放不下的错误，抓住核心实体就好：user、subject、wrong_question、knowledge_point、review_record。关系标注清楚，user与wrong_question是一对多，subject与wrong_question是一对多，wrong_question与knowledge_point是多对多，review_record与wrong_question是多对一。每个实体的属性只画核心的，比如wrong_question画出题干、答案、错误原因、难易度、掌握状态这些关键属性就够了。

在论文里描述表结构时，每张表附一个字段说明表格，字段名、类型、约束、注释四列。这个部分最容易出问题的是字段注释不完整，比如options字段要写明“为JSON格式选择题选项”而只写“选项”两个字，评委老师一眼看去会认为设计不严谨。

6.4 第五章“系统实现”的写法：代码怎么贴才有说服力

很多同学的论文实现章节是纯页面截图加大段代码堆砌，这种写法不及格。好的写法是“功能描述+核心代码片段+实现思路说明”，每个功能点都遵循这个模式。以错题筛选功能为例，不要全文贴几百行Mapper XML，只贴动态SQL的核心片段，然后写清楚“这里利用MyBatis的 和 标签实现了多条件动态组合查询，避免拼接SQL语句造成的SQL注入和查询性能问题”，这样才是评委想看到的“设计思路表达”。

6.5 测试章节的设计：不仅要测功能，还要测边界

功能测试用例表是系统测试章节的主体。测试用例表要包括用例编号、测试项、测试步骤、预期结果、实际结果、是否通过。除了正常的测试路径外，一定要加入“逆向用例”，比如未登录访问系统、输入超长题干、重复提交表单、删除不存在的错题ID——这些边界情况是展示思考深度的最佳位置。

这里再补充一个测试思路：并发操作测试可以设计一个场景，比如两个浏览器同时录入同一道错题，验证系统不会产生重复数据。后端的唯一性约束和前端按钮的loading状态都能在这个用例里体现，说起这个测试用例，答辩时故事感会非常强。

7. 开发过程中最值得记录的七个坑

7.1 前端图片上传的URL访问路径与虚拟目录映射

这不是第一次提到，但它确实是毕设高峰月的头号问题。Tomcat部署的后端项目，上传图片保存到/uploads目录后，在浏览器直接访问图片URL是404。原因是参数没配，解决方式是在Spring的addResourceHandlers中配置本地磁盘目录到URL的映射。

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

同时在application.properties或spring-mvc.xml里配置一个uploadDir变量。注意uploadDir要写成以/结尾的绝对路径，否则映射会少掉一级目录，非常隐蔽。

7.2 分页查询时总数与列表数据不一致

MyBatis搭配PageHelper做分页时，如果分页查询的表带有聚合函数（比如错题表关联知识点列表），查询出的总数会比实际错题数多很多。原因是聚合查询把中间表的多条记录也算了进去。解决方式有两种：要么在Mapper里写两条SQL把总数查询和列表查询拆开，要么使用SELECT DISTINCT wq.id配合子查询。如果不用PageHelper而是自己写LIMIT，那SQL里要把GROUP BY和COUNT(DISTINCT wq.id)分开处理，不然总数会虚高。

7.3 前端传日期字符串导致后端时间的时区偏移

前端传一个"2026-03-15 10:00:00"字符串过来，后端接收后变成2026-03-15 02:00:00，这种时区偏移问题非常磨人。根因是Jackson反序列化时使用的默认时区是UTC，而数据库连接配置时区与服务器不一致。解决方式是在Spring配置文件里统一指定时区，同时在响应前端的JSON格式里也带上时区信息。这个坑在演示环节出现过一次，展示统计报表时，某天的记录跑到了前一天，非常尴尬。

7.4 Vue打包后部署到Tomcat，刷新子路由404

前端项目开发完要构建部署，打包后的dist目录放到Tomcat的webapps下，访问主页正常，但点击某个子路由再刷新页面，Tomcat返回404。解决方式是在Web.xml或SpringMVC的配置中加入forward支持，把所有不带后缀的路径转发到index.html。需要说明的是，Vue Router要改为history模式还是维持hash模式，这个选择与部署方案强相关。如果用的是Tomcat直接部署，hash模式反而省掉很多配置；如果nginx反向代理就简单得多。

7.5 错题批量导入的乱码问题

如果系统提供批量导入错题功能（这是论文里的扩展点），从Excel模板读中文数据时最容易遇到乱码。处理方式有两个关键：保证demo模板文件用UTF-8编码生成；在解析Excel时显式设置字符集。另外模板设计时要加入“题型”下拉项约束（数据有效性校验），能避免大量脏数据导入。别看这个功能是附加的，写进论文里作为系统扩展和思考深度特别加分。

7.6 统计图表数据为空时，页面白屏

正确率趋势图查询结果为空数组时，如果不加判断直接传给ECharts，图表区域会报错或白屏。我用一个数据兜底函数来做处理，当数组为空、长度为0、数组里的值全是0时，显示“暂无数据”的提示而不是空图表。这类边界处理在论文测试章节的反向用例里可以写成正式条目，评委老师看到时观感非常好。

7.7 数据库表名的保留字段与关键字冲突

如果你把表名命名为user或subject，在MySQL上会触发保留字的限制。表名加反引号可以临时处理，但规范做法是表名采用sys_user、sys_subject加前缀，或者换成student、course这类不会冲突的命名。错题表里的source字段也是个隐藏的保留字，我一度因为在Excel导入时insert into ... source字段报错排查了很久——列名最好是question_source等不含歧义的命名。

8. 把系统从能跑变成能答辩：部署、演示与加分项

8.1 本机演示环境的搭建与注意事项

答辩前最慌的情况是什么？打开浏览器发现服务起不来或数据库连不上。建议提前把环境封装成三个固定环节：MySQL数据库执行一遍初始化脚本；后端IDEA里直接以Tomcat运行，端口固定为8080；前端npm run serve起在8081端口，这里主要是dev server避免与后端端口冲突。

数据库里预置的演示数据一定要有“讲故事”的能力。比如录入一个月内的30道错题，分布在不同科目、不同知识点下，用户复习记录里有部分“已掌握”和部分“需巩固”，这样打开统计页时图表才会有形态。哪怕只是那么点数据，PPT视觉效果和答辩叙事质感会完全不一样。同时演示路径要设计好：登录-看统计总览-筛选某一科目的错题列表-进入错题详情编辑掌握状态-回到统计页看到图表变化。这一套流程走下来，系统的完整性和逻辑连贯性全都能体现。

8.2 论文里可以放的三个扩展功能

作为导师指导过的项目，我觉得这个系统有几个扩展点如果能做出来，论文评级会上升半级到一级：

• 自定义复习计划：基于遗忘曲线（艾宾浩斯）生成复习提醒，用户按计划进行复习打卡，系统更新掌握状态。
• 错题导出PDF：后端使用模板引擎导出当前筛选条件下的错题PDF文件，适合考前打印复习。
• 基于知识点的薄弱环节检测：把错误率高于阈值的知识点标注为薄弱点，为后续学习提供优先级建议。

其中第三个扩展点在论文里可以放到“系统展望”或“改进方向”，不一定必须实现。但如果时间充裕，做出来就是“算法含量”的展示，答辩时关于“你这里有什么创新点”这个问题会非常好回答。

最后讲一点个人体会。错题管理系统从外部看是个常见选题，但真正把它做扎实并不轻松，技术细节非常多，接口设计、数据建模、前后端联调每一步都藏了坑。也正因如此，它才是一个能锻炼人且拿得出手的毕设题目。投入的每一天开发都会直接转化成论文里能写、答辩里能说的东西，这就是这个题目最有价值的地方。动手做的时候不要怕踩坑，把遇到的问题记下来，那些记录本身就是第二份收获。