先说一个我观察到的现象市面上的“课程答疑系统”绝大多数是拿论坛源码或工单系统改的把发帖叫“提问”把回帖叫“回答”角色换一下就交差了。这东西不是不能用但离真实的课堂场景差得远——没有课程归属、没有教师身份边界、没有“采纳答案”后的闭环反馈学生问完问题根本不知道有没有人被通知到。最近我把这套基于SpringBootVue的课程答疑管理系统重新从零写了一遍数据层用MyBatis和MySQL整个过程走下来最大的体会是这类系统的难点根本不在CRUD而在状态流转、权限边界和对用户体验的细节处理上。这篇文章我不打算讲怎么新建一个SpringBoot项目这种基础步骤而是把这套系统里几个最影响体验的设计选择拆开来说透——问题状态机怎么设计、MyBatis里哪些坑值得避开、Vue路由怎么配才不会在打包进SpringBoot之后404以及一套能直接跑起来演示的初始化数据该怎么准备。无论你是正在做毕业设计的学生还是想通过一个完整全栈项目巩固后端能力的开发者这篇内容应该都能帮你少走几步弯路。1. 课程答疑系统的边界它和“论坛”到底差在哪1.1 三种角色分别管什么我在动手建表之前先花了一天时间把角色边界画清楚这是整个系统里性价比最高的一次设计投入。课程答疑系统至少要有三种角色学生、教师、管理员。学生能做的事很明确登录后在课程下发起提问对自己提出的问题可以补充内容可以点赞他人的回答可以在某个回答让自己满意时将其采纳为“最佳答案”。这里有个容易被忽略的细节——学生只能采纳“自己提出的问题”下的回答不能去别人问题底下随便点采纳这个校验在后端Service层必须做而不能只靠前端把按钮隐藏。教师的核心动作是“回答问题”和“管理自己课程下的问题”。一套真实可用的答疑系统里教师不应该看到全校所有课程的问题而是只能看到自己名下课程的问题列表。所以课程表和教师之间要有关联关系简单设计就是course表直接存一个teacher_id一门课只归属一位负责老师这比搞多对多课程教师关联表更容易理解和维护。管理员管的是基础数据创建课程、分配教师、重置用户密码、查看全站答疑统计。管理员不该深度介入某个具体问题的回答环节否则他会慢慢变成所有问题的“接盘侠”这是我在早期版本里踩过的坑。1.2 功能清单哪些必须有哪些是加分项我最终落地的功能清单如下标注了优先级方便你对照自己的项目做裁剪模块功能优先级说明登录注册JWT登录、注册、退出必须有前后端分离下Session不好用JWT是主流选择课程模块课程列表、课程详情必须有按课程维度组织问题提问模块按课程发起问题、查看我的问题必须有标题Markdown正文回答模块教师/学生回答问题必须有同一个问题允许多条回答采纳闭环提问者采纳一条回答必须有被采纳后问题状态变为已解决点赞对回答点赞加分项排序权重之一站内信新回答、被采纳、被点赞通知必须有这是答疑系统体验的关键相似问题推荐提问时提示可能已有答案加分项减少重复提问演示效果很好教师工作台按课程查看待回复问题加分项方便教师快速处理这一版把“必须有”全部做完“加分项”我做了相似问题推荐和教师工作台因为它们对答辩和演示效果的提升非常明显后面我会详细说实现思路。1.3 2025年这套技术栈为什么这样选标题写的是SpringBootVueMyBatisMySQL这个组合在2025年依然是全栈项目的主流配置我的选型理由是这样的后端用SpringBoot 3.x对应JDK 17。如果你还在用SpringBoot 2.x和JDK 8我不是说不能用但新项目没必要绑在旧版本上。SpringBoot 3.x的javax包已经迁移到jakarta网上很多教程里的import语句直接粘过来会报错这一点需要提醒新手注意。ORM层我选了原生MyBatis而不是MyBatis-Plus。原因有两个一是这套系统的核心查询大多是多条件动态SQLXML Mapper写起来比注解要清晰得多MyBatis原生能力足够二是很多面试官和答辩老师对MyBatis-Plus过度的自动CRUD有一些偏见原生MyBatis更能体现你对SQL的控制力。后面我专门有一节讲XML Mapper的写法。前端用Vue 3 ViteUI库用Element Plus。Vue 2已经停止维护了新项目直接用Vue 3组合式API。状态管理用PiniaVuex在Vue 3里虽然有兼容版但官方已经推荐Pinia了不要在这个问题上纠结。数据库用MySQL 8.0字符集统一utf8mb4。MySQL 5.7还在服役但8.0的窗口函数、更好的JSON支持和公共密钥检索机制都是实打实的优势新装环境别再去下载5.7了。2. 表结构与问题状态机先把数据模型立住2.1 核心表Design五张表就够了这个系统不需要二十张表五张核心表就能覆盖全部业务。我列一下实际建表的核心字段。用户表简化了角色设计用role字段区分三种身份CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, nickname varchar(50) DEFAULT NULL COMMENT 展示名称, avatar varchar(255) DEFAULT NULL COMMENT 头像URL, role varchar(20) NOT NULL DEFAULT STUDENT COMMENT STUDENT/TEACHER/ADMIN, gmt_create datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, gmt_update datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;课程表字段少但teacher_id外键不能省这是教师工作台的数据基础CREATE TABLE course ( id bigint NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL, description varchar(500) DEFAULT NULL, teacher_id bigint NOT NULL COMMENT 主讲教师, status tinyint NOT NULL DEFAULT 1 COMMENT 1启用 0停用, gmt_create datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_teacher_id (teacher_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT课程表;问题表是所有表里信息量最大的我用表格展示字段设计逻辑字段名类型说明idbigint主键course_idbigint所属课程索引必建user_idbigint提问学生索引必建titlevarchar(100)问题标题搜索主字段content_mdtextMarkdown格式正文tagsvarchar(255)逗号分隔的标签如“Java,Spring”statusvarchar(20)OPEN/ANSWERED/RESOLVEDview_countint浏览次数like_countint点赞数is_deletedtinyint软删除标记gmt_create / gmt_updatedatetime时间戳回答表是闭环的落点最关键的是is_adopted字段CREATE TABLE answer ( id bigint NOT NULL AUTO_INCREMENT, question_id bigint NOT NULL, user_id bigint NOT NULL, content_md text NOT NULL, is_adopted tinyint NOT NULL DEFAULT 0 COMMENT 是否被采纳, like_count int NOT NULL DEFAULT 0, gmt_create datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_question_id (question_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT回答表;加上一张站内信表整个数据模型就完整了。站内信表我放在第5节细讲它字段不多但时机很关键。2.2 状态机为什么用字符串状态而不是数字问题状态我设计了三个OPEN待回答、ANSWERED已有回答、RESOLVED已解决。流转规则是这样学生提交问题后状态为OPEN只要有任意用户提交了一条回答状态变为ANSWERED提问者在回答列表里点“采纳”该回答is_adopted置1问题状态变为RESOLVEDRESOLVED的问题不允许再被采纳其他回答但依然可以继续回答和点赞也允许提问者追加内容。这里有一个很隐蔽的设计点状态字段到底用tinyint还是varchar。我第一次做的时候用的是tinyint0、1、2三个数字写进代码里三个月后回头看代码完全不知道0代表什么。后来我改成varchar存字符串读代码和排查问题都舒服得多。MySQL存字符串比数字多占一点空间对这种量级的系统完全可以忽略。另一个关键是状态流转不能被跳过。采纳操作的Service事务里必须校验当前状态和提问者身份伪代码如下Transactional public void adoptAnswer(Long questionId, Long answerId, Long currentUserId) { Question question questionMapper.selectById(questionId); if (question null || question.getIsDeleted() 1) { throw new BizException(问题不存在); } if (!question.getUserId().equals(currentUserId)) { throw new BizException(只有提问者才能采纳回答); } if (RESOLVED.equals(question.getStatus())) { throw new BizException(该问题已解决不能重复采纳); } Answer answer answerMapper.selectById(answerId); if (answer null || !answer.getQuestionId().equals(questionId)) { throw new BizException(回答不存在或不属于当前问题); } questionMapper.updateStatus(questionId, RESOLVED); answerMapper.updateAdopted(answerId, 1); // 发送站内信给回答者你的回答被采纳了 notifyService.sendAdoptNotify(answer.getUserId(), questionId); }这个方法的Transactional必须加在public入口上这样才能保证question状态更新和answer采纳标记要么都成功、要么都回滚。如果分两个Mapper调用但不在同一事务里一旦更新完问题状态后通知发送失败用户看到的状态和实际答案标记就不一致了。2.3 并发更新和软删除的细节答疑系统的并发量不会很高但有几个细节值得注意。点赞操作不要先SELECT再UPDATE直接用原子SQL更新UPDATE answer SET like_count like_count 1 WHERE id #{answerId}这样就算同一时间来了五个点赞请求也不会出现并发覆盖。软删除方面用户删掉自己的问题后回答应该一并逻辑隐藏。这个问题我在第一版偷懒没做后来发现用户删除问题后回答列表还挂在数据库里统计时数据也不对。正确做法是删除问题时把该问题下的所有回答也标记is_deleted查询时统一加上过滤条件。3. MyBatis实战动态SQL、TypeHandler与二次缓存三处关键点3.1 为什么必须用XML Mapper这套系统里最复杂的一条查询是“课程问答列表”。它要支持多条件组合按课程过滤、按状态过滤、按关键词模糊搜索标题或正文、按点赞数或时间排序、分页。这种SQL用注解写会很痛苦注解里拼 标签的字符串丑到难以维护。XML Mapper是正解可读性和可维护性都远超注解。我贴一条典型的问题分页查询select idselectQuestionPage resultTypecom.demo.entity.Question SELECT q.id, q.course_id, q.user_id, q.title, q.content_md, q.tags, q.status, q.view_count, q.like_count, q.gmt_create, u.nickname AS userName FROM question q LEFT JOIN user u ON q.user_id u.id where q.is_deleted 0 if testcourseId ! null AND q.course_id #{courseId} /if if teststatus ! null and status ! AND q.status #{status} /if if testkeyword ! null and keyword ! AND (q.title LIKE CONCAT(%, #{keyword}, %) OR q.content_md LIKE CONCAT(%, #{keyword}, %)) /if /where choose when testorderBy like ORDER BY q.like_count DESC, q.gmt_create DESC /when otherwise ORDER BY q.gmt_create DESC /otherwise /choose LIMIT #{offset}, #{pageSize} /select这里的关键是要用 标签自动处理条件连接避免出现WHERE后面直接跟AND的语法错误。 是很多新手不熟悉的标签它可以实现排序策略的切换比在Java代码里拼字符串干净得多。分页这里我建议手写LIMIT不要引入PageHelper。PageHelper的原理是ThreadLocal存储分页参数在高并发服务里线程复用可能出现页码串号的问题排查起来非常隐蔽。对这个体量的系统手写LIMIT带offset和pageSize完全够用代码一眼就能看明白。3.2 MySQL排序和分页的配合问题列表页通常有两个排序维度按最新时间、按点赞数。MySQL在执行ORDER BY的时候如果排序字段没有索引会对结果集进行文件排序。问题表数据量在几千行级别时感觉不明显但一旦上了讲师工作台、所有课程问题混在一起查排序字段的索引就该建了。我实际建的索引策略是question表(course_id, status, gmt_create)联合索引覆盖教师工作台的查询条件question表(user_id, gmt_create)联合索引覆盖“我的问题”列表answer表(question_id, gmt_create)联合索引覆盖回答列表查询。这里有个小教训联合索引的最左前缀原则是真实的。索引(course_id, status, gmt_create)能加速course_id单条件查询、course_idstatus双条件查询、三条件全查询但如果你只按status查这个索引完全帮不上忙。设计联合索引前先看看你的查询到底以哪个字段作为第一条件。3.3 自定义TypeHandler处理标签字段问题表的tags字段我存的是“Java,SpringBoot,MyBatis”这样的逗号分隔字符串但Java实体里想直接用List 接收这就轮到TypeHandler出场了。实际上这里存成字符串直接接收也可以但作为一个练习TypeHandler的机会价值不小——面试时TypeHandler是个高频考点亲手实现一次比背八股文有用得多。自定义TypeHandler的核心逻辑是把Java的List 转成数据库的字符串再把数据库字符串转回ListMappedTypes(List.class) MappedJdbcTypes(JdbcType.VARCHAR) public class StringListTypeHandler extends BaseTypeHandlerListString { Override public void setNonNullParameter(PreparedStatement ps, int i, ListString parameter, JdbcType jdbcType) throws SQLException { ps.setString(i, String.join(,, parameter)); } Override public ListString getNullableResult(ResultSet rs, String columnName) throws SQLException { return splitToList(rs.getString(columnName)); } Override public ListString getNullableResult(ResultSet rs, int columnIndex) throws SQLException { return splitToList(rs.getString(columnIndex)); } Override public ListString getNullableResult(CallableStatement cs, int columnIndex) throws SQLException { return splitToList(cs.getString(columnIndex)); } private ListString splitToList(String value) { if (value null || value.isEmpty()) { return Collections.emptyList(); } return Arrays.asList(value.split(,)); } }Mapper接口里对tags字段标注ListQuestionVO selectQuestionList(Param(courseId) Long courseId);然后在XML的resultMap里把tags列的typeHandler配上resultMap idquestionVOMap typecom.demo.vo.QuestionVO id propertyid columnid/ result propertytags columntags typeHandlercom.demo.handler.StringListTypeHandler/ /resultMap这个知识点很多教程只在概念层面讲一遍但自己写一遍就能理解MyBatis在结果映射时到底做了什么——它就是利用typeHandler把JDBC的String转换成了Java的List。3.4 二级缓存这个项目里我的结论是“不开”MyBatis的二级缓存是面试高频题真实项目里却要慎用。我先说结论课程答疑系统我没开二级缓存原因是收益小、风险大。二级缓存是namespace级别的把一次查询的结果缓存起来要求查询对象可序列化。问题在于答疑系统的数据是动态的学生提交了新回答、教师采纳了一条回答同一namespace下别的用户查询结果如果还在缓存里就会看到过期数据。MyBatis的二级缓存粗粒度失效机制很难精确控制复杂度上来了收益却有限。我的替代方案是只读且变化不频繁的基础数据课程列表用本地缓存答疑相关的实时数据直接查MySQL。这个量级的系统MySQL单表轻松扛住上万条数据完全不是性能瓶颈。如果你真的需要缓存请上Redis并且精细设计缓存key而不是指望MyBatis二级缓存替你解决。3.5 数据源配置与两个必踩的MySQL报错这里分享一个我每次搭环境都会提醒自己的配置application.yml里MySQL连接串这么写spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/course_qa?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456两个必踩的坑都出在MySQL 8上。第一个是SSL连接错误。MySQL 8默认开启SSL如果你的连接串不加useSSLfalse本地开发环境会出现SSLHandshakeException或者警告刷屏。有些同学会加useSSLtrue然后本地MySQL证书配置不对又报错。本地开发直接useSSLfalse最省心。第二个是Public Key Retrieval错误。MySQL 8默认使用caching_sha2_password插件客户端第一次连接需要从服务器获取公钥。如果你的连接串漏掉allowPublicKeyRetrievaltrue会出现Public Key Retrieval is not allowed的异常。这个参数网上很多教程不会提遇到报错时几乎没人能第一眼想到是这里的问题。开发阶段想打印SQL方便调试加到application.ymllogging: level: com.demo.mapper: debug注意这里的com.demo.mapper要换成你自己的Mapper接口包名MyBatis的SQL日志是绑定到Mapper接口的logger上的写错包名日志是不出来的。4. Vue 3前端与联调路由、渲染、打包“三板斧”4.1 前端路由设计简单方案最稳前端路由我用的Vue Router 4整张路由表如下路径组件角色限制/loginLogin.vue无/homeHome.vue登录用户/course/:idCourseDetail.vue学生/教师/question/:idQuestionDetail.vue登录用户/my/questionsMyQuestions.vue学生/teacher/questionsTeacherQuestions.vue教师/admin/coursesAdminCourses.vue管理员关于“动态路由”很多人在Vue 3项目里看到“动态路由”这个词就想着用addRoute按权限动态注册路由表。我的建议是不要为了炫技过度设计。对答疑系统这种角色数量固定的项目在路由meta里标记roles用全局前置守卫判断当前用户角色是否在允许列表里这就是最清晰、最稳定、最容易向别人解释的方案。// router/index.js const routes [ { path: /teacher/questions, component: () import(../views/TeacherQuestions.vue), meta: { roles: [TEACHER, ADMIN], requiresAuth: true } }, { path: /admin/courses, component: () import(../views/AdminCourses.vue), meta: { roles: [ADMIN], requiresAuth: true } } ] router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) return } const userRole localStorage.getItem(userRole) if (to.meta.roles !to.meta.roles.includes(userRole)) { next(/home) return } next() })用addRoute实现动态路由的坑在于刷新页面后路由表是从接口重新获取的如果获取失败用户明明已登录却掉进404。我们的简单方案完全规避了这个风险。4.2 Markdown渲染与XSS防护问题详情和回答内容都是Markdown格式。我在前端用marked做解析但是这个方案有一个容易被忽略的安全隐患——Markdown里可以嵌HTML如果学生提交问题内容里有