SSM+Vue培训管理系统毕设全攻略：从数据库设计到答辩准备

又到了一年一度毕设选题的季节，每年这个时候我都会收到一堆类似的咨询：老师给了一个“凌志软件培训管理系统”的题目，要基于SSM+Vue做，还要写论文，到底怎么入手？说实话，这类系统在毕设选题中属于典型的中等难度题目——业务边界清晰，技术栈主流，既有后端逻辑又有前端交互，很容易做出完整度。但正因为它“看起来不难”，很多学生反而容易做得平庸，最后在答辩时被问住。这篇文章我就把自己做这套系统时的完整思路复盘一遍，从选题拆解、数据库建模、后端设计、前端联调，到论文组织和答辩准备，尽量把那些零散经验一次性讲透，希望能给正在做或准备做这个题目的同学一个参考。

先说结论：这套系统的核心价值不在于“技术多新”，而在于“业务闭环完整”——用户从注册、选课、报名、上课记录、考试到成绩查看，是一条完整的链路。只要把这条链路的每一环都落稳，论文自然有东西写，代码也经得起问。

1. 为什么是SSM+Vue：毕设选题与技术栈的复盘逻辑

1.1 凌志软件培训管理系统到底要解决什么业务问题

很多同学拿到题目第一反应是搜代码、找现成项目，其实这是最危险的做法。正确思路是先搞清楚这个系统面对的角色和业务流程。凌志软件培训管理系统，核心场景是培训机构或企业内部培训部门管理培训业务，角色大概分成三类：管理员（教务人员）、讲师（培训老师）、学员（参训员工或学生）。

从业务链路看，管理员要维护课程信息、安排培训计划、审核学员报名、分配讲师、录入成绩；讲师要查看自己负责的班级和学员，可能还要上传课件或布置作业；学员要浏览课程、报名、查看课表、查看成绩和培训记录。这三类角色对应的功能边界如果不在前期厘清，后面写代码就会陷入“功能越多越好”的误区，最后做出一堆没人用的功能，论文还没法自圆其说。

我建议把系统按模块拆成四个核心区域：系统管理（用户、角色、菜单、权限）、培训业务（课程、班级、报名、签到、成绩）、资源管理（课件上传、培训视频、试题）、统计报表（培训完成率、成绩分布、课程热度）。这四个区域基本覆盖了毕设评委会关注的业务完整度，又不至于过于发散。

1.2 技术栈选型的“稳妥”与“亮点”如何平衡

SSM（Spring + SpringMVC + MyBatis）加 Vue 的组合，在2026年依然有大量学校在用，原因很简单：SpringMVC负责请求分发，MyBatis负责数据持久化，Vue负责前端交互，三者各司其职，分层清晰，非常适合用来考察学生对Web开发整体流程的理解。相比Spring Boot的“开箱即用”，SSM需要手动整合各种配置，反而能体现你对框架底层原理的掌握程度，在答辩时这是一个可以打的点。

不过这里有一个分歧：很多学生倾向于用Vue 2还是Vue 3？我的建议是直接上Vue 3。虽然网上SSM的模板大部分是Vue 2写的，但Vue 3的Composition API在逻辑复用和代码组织上明显更优，而且现在Vue 3已经是绝对主流，答辩老师大概率也会问“为什么不用Vue 2”。你可以回答：Vue 3的响应式机制基于Proxy，性能更好，组合式函数更方便抽取公共逻辑，我和SSM后端通过Axios交互，前端工程化和后端分层没有直接冲突。这个回答比“因为我学的Vue 2”要专业得多。

还有一点容易忽略：SSM的“M”虽然是MyBatis，但很多学校已经把MyBatis Plus纳入了允许范围。如果老师没有明确禁止，用MyBatis Plus能省掉大量单表CRUD的XML编写时间，让你把精力集中在业务逻辑和复杂查询上。但前提是——论文里要写清楚你用了MyBatis Plus，因为它是MyBatis的增强封装，不影响你解释“持久层框架”的定位。如果老师比较传统，那就老实写Mapper XML，两种方案我都试过，后面会讲到各自的坑。

2. 从需求到数据库：培训管理系统的核心表设计与建模细节

2.1 用户、角色、班级、课程、报名五张核心表的关系梳理

数据库设计是论文里最容易被老师翻看的部分，也是后续写代码的地基。培训管理系统最少需要拿下这几张表：

注意一个关键设计点：class_info 表里有一个 teacher_id，但老师本质上也是 sys_user 里的一个用户。这样设计的好处是讲师登录后可以直接查“我带的班级”，管理员也可以统一管账号。而 sign_up 表里的 status 字段，建议用 0-待审核 1-已通过 2-已拒绝 3-已取消 这类数字字典，而不是字符串，这样后续统计和筛选都方便。

2.2 培训状态流转与数据冗余的设计取舍

很多初学者在设计表时会陷入“一刀切三范式”的执念，觉得任何冗余都是错的。实际上在培训管理这个场景里，适度冗余非常有用。举一个例子：报名表 sign_up 里除了 class_id，我建议额外冗余一个 course_name 和 course_start_time。原因是学员端的“我的培训”列表最常显示的就是课程名和时间，如果不冗余，每次列表查询都要关联课程表，多一次join，SQL复杂度和出错率都会上升。这在数据量小的毕设项目里虽然没什么性能压力，但能让代码更清晰，也能在论文“数据库优化”一节有东西可写。

状态流转也是培训系统的灵魂。一个完整的培训流程是：学员查看课程 → 报名 → 管理员审核 → 进入班级 → 参加培训 → 讲师录入成绩 → 学员查看成绩 → 获得完成状态。我建议把这套流转画成一张状态图放在论文里，同时在后端用状态机思想做一个简单的状态校验。具体实现上，可以定义一个枚举类 SignUpStatusEnum，在Service层每次更新状态前做前置状态判断，防止用户从“已拒绝”直接跳到“已完成”这种逻辑漏洞。这类细节是答辩时展示“工程素养”的经典案例，比单纯堆功能有用得多。

2.3 成绩和评价模块怎么建表才不返工

成绩表是最容易设计失误的地方。刚开始我按课程建表，也就是每门课单独一张成绩表，后来发现新增课程就要新增表，导师直接否了。正确做法是设计一张通用的 score 表，用 class_id + user_id 作为唯一约束。这里还有一点容易忽略：一次培训可能既有笔试成绩又有实操成绩，甚至还有平时分。建议在 score 表里加一个 score_type 字段（1-平时 2-笔试 3-实操），然后用 class_id + user_id + score_type 做联合唯一索引。这样论文里演示“成绩构成分析”的时候，可以像模像样地写一个加权平均的SQL，评委会觉得你有思考深度。

评价字段也建议单独建表或者放进score表。我当时的做法是给 score 表加了一个 evaluate 长文本字段，讲师录入成绩时可选填评语，学员端“我的成绩”页面会展示评语。这个功能实现成本极低，但会让系统看起来“有人情味”，在演示环节尤其加分。

3. SSM后端落地：Controller、Service、Mapper的分层实现与埋坑点

3.1 Service层事务的坑：为什么只加@Transactional还不够

SSM项目的经典分层是 Controller → Service → Mapper，大部分同学都会写，但真正容易翻车的是事务控制。培训系统的报名功能就是一个典型场景：用户报名时要同时更新 sign_up 表插入记录、把班级表的 current_student 加一、可能还要往 study_record 里初始化一条学习记录。这三个操作必须在一个事务里完成，否则会出现“报名成功但班级人数没变”的数据不一致。

用Spring声明式事务就是一句话的事，在Service实现类或方法上加 @Transactional。但这里有几个隐藏坑：第一，@Transactional 默认只对 RuntimeException 回滚，如果你在业务代码里自行捕获了异常并吞掉，事务是不会回滚的。所以Service里不要轻易 try-catch，要么让异常向上抛，要么在catch里手动 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第二，SSM整合Spring的配置中，必须加 <tx:annotation-driven transaction-manager="transactionManager" /> 或者在Spring配置里配置 DataSourceTransactionManager。我见过不止一个同学，代码写得没问题，但因为忘了在Spring配置文件里开启注解事务，导致事务完全不生效，查了半天。

一个实际的报名逻辑代码参考结构：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public Result signUp(Integer classId, Integer userId) {
    // 1. 校验班级是否存在且未满
    ClassInfo classInfo = classInfoMapper.selectById(classId);
    if (classInfo == null || classInfo.getCurrentStudent() >= classInfo.getMaxStudent()) {
        return Result.error("班级不存在或已满");
    }
    // 2. 校验是否重复报名
    SignUp exist = signUpMapper.selectByClassIdAndUserId(classId, userId);
    if (exist != null) {
        return Result.error("请勿重复报名");
    }
    // 3. 插入报名记录，更新班级人数，初始化学习记录
    signUpMapper.insert(new SignUp(classId, userId, 0));
    classInfoMapper.increaseCurrentStudent(classId);
    studyRecordMapper.init(classId, userId);
    return Result.ok();
}

rollbackFor = Exception.class 一定要写，这是老生常谈但每届都有人犯。

3.2 MyBatis动态SQL如何优雅实现多条件课程查询

课程列表页是培训系统的核心页面，学员要按课程名称、分类、培训时间段、讲师、状态等条件筛选课程。如果直接用JDBC拼接SQL会非常痛苦，MyBatis的 <where> <if> 标签可以很好地解决这个问题。

以课程多条件查询为例，Mapper XML可以写成这样：

xml复制<select id="selectByCondition" resultType="com.example.entity.Course">
    SELECT c.*, u.real_name AS teacher_name
    FROM course c
    LEFT JOIN sys_user u ON c.teacher_id = u.id
    <where>
        <if test="name != null and name != ''">
            AND c.name LIKE CONCAT('%', #{name}, '%')
        </if>
        <if test="categoryId != null">
            AND c.category_id = #{categoryId}
        </if>
        <if test="status != null">
            AND c.status = #{status}
        </if>
        <if test="startDate != null">
            AND c.start_time &gt;= #{startDate}
        </if>
        <if test="endDate != null">
            AND c.start_time &lt;= #{endDate}
        </if>
    </where>
    ORDER BY c.create_time DESC
</select>

注意这里 > 和 < 是因为XML中不能直接使用大于小于号。动态SQL写起来确实挺顺利，但有一个体验问题：当条件超过5个时，Mapper接口的参数最好封装成一个DTO对象，否则方法签名会很长，而且代码审阅时很难看。另外，多条件查询对应的Mapper方法返回的 Course 对象中，建议加一个 teacherName 的非表字段，专门承接LEFT JOIN查出来的讲师名字，而不是前端再发一次请求去查讲师信息。这个字段在实体类上用 @TableField(exist = false)（MyBatis Plus）或直接不映射（原生MyBatis）标注即可。

3.3 文件上传、Excel导出和培训视频管理：演示时的三个加分项

培训管理系统一般会涉及课件上传、成绩导入导出、培训视频播放等功能。这三个功能是典型的“看着高级、做起来不算难”的加分项，但每个都有坑。

文件上传要注意服务器部署路径问题。本地用 File.separator 拼接路径很顺利，但打成war包部署到Linux后，路径分隔符、目录权限、中文文件名都会变成大坑。建议把上传目录配置在外部配置文件里，而不是写死在代码中。例如在 application.properties 或 config.properties 中定义：

properties复制file.upload-dir=/data/training/upload/

上传接口里，要限制文件类型和大小，防止传木马或超大文件。用SpringMVC的 MultipartFile 接收时，可以在Controller里做一层校验，也可以配置 CommonsMultipartResolver 的 maxUploadSize。课件上传时还要考虑重名问题，我习惯用 UUID + 原始文件名 重命名存储，这里有个小建议：数据库里存文件名和访问路径，但磁盘上的文件名用UUID，别用中文，否则前端展示时会遇到URL编码的坑，例如“课程大纲.doc”在Chrome里会自动编码，到了某些浏览器上就404。

Excel导入导出，如果学校允许引入第三方库，直接用EasyExcel或Apache POI。这里不建议手写解析。但要注意一点：EasyExcel导出时如果字段上用了 @ExcelProperty 注解，实体字段名必须和表头对应，不然导出的Excel表头是乱码或错位。还有中文表头的文件编码，最好统一用UTF-8，并在导出时设置响应头：

java复制response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet");
response.setCharacterEncoding("utf-8");
response.setHeader("Content-disposition", "attachment;filename=score.xlsx");

培训视频管理就更讲究了。毕设阶段不用做复杂的转码服务，把视频文件传上去，前端直接用 <video> 标签播放即可。但如果导师要求在线点播、进度记忆，就要考虑视频格式兼容性问题。如果视频是.m3u8格式（HLS流媒体），Vue前端需要引入如 hls.js 或 video.js 插件来播放。我在做“学员端视频课”模块时，前后端分离部署后，发现直接用 <video> 播放mp4没问题，但播放m3u8在Chrome里会有跨域问题，因为 .m3u8 内部引用的 .ts 分片地址如果返回的是相对路径，浏览器解析时会基于当前前端域名去请求，而流媒体服务在另一个端口，就报跨域。解决思路有两种：一是后端在响应头加上 Access-Control-Allow-Origin，二是前端用 hls.js 配置好 xhrSetup，由前端发起的请求自动携带跨域头。毕设里建议直接用mp4格式演示，如果非要用m3u8，至少把CORS配置弄清楚，别在演示时翻车。

4. Vue前端对接调试：从Vue 3环境搭建到前后端联调的真实过程

4.1 本地开发环境配置与跨域问题排查

Vue开发环境搭建应该是所有同学都经历的“安装地狱”环节。Node.js版本和npm源的坑就不细说了，建议用nvm管理Node版本，使用LTS版本，npm源切换到国内镜像。这里重点说前后端分离项目的跨域问题。

后端SSM项目默认运行在Tomcat的8080端口，Vue开发服务器默认运行在5173（Vite）或8080（webpack的vue-cli，但容易和后端冲突），两个端口不同，浏览器发请求必然跨域。解决方案有几种：

一种是后端CORS过滤器全局加跨域头：

java复制public class CorsFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
        HttpServletResponse response = (HttpServletResponse) res;
        response.setHeader("Access-Control-Allow-Origin", "http://localhost:5173");
        response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS");
        response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization");
        chain.doFilter(req, res);
    }
}

另一种更推荐：在Vue工程里配置开发环境的代理。以Vite为例，在 vite.config.js 里写：

javascript复制server: {
  port: 5173,
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true,
      rewrite: (path) => path.replace(/^\/api/, '')
    }
  }
}

这样前端代码里所有请求都发到 /api 开头，Vite开发服务器会把请求转发到后端8080，从浏览器视角看所有请求都是同源的，就没有跨域了。这里有个极其常见的问题：proxy 配置后，页面登录请求发到 /api/user/login，后端接口实际路径是 /user/login，如果不加 rewrite 会404。很多同学卡在这一步，以为配置无效，其实是路径没重写。还有一种情况是后端项目有context-path，比如部署路径是 http://localhost:8080/ssm，那target要写成 http://localhost:8080，rewrite时要把请求路径拼上/ssm，这个细节要灵活处理。

4.2 Axios封装、登录态与路由守卫构成的权限闭环

Vue前端和后端交互的核心是Axios，我建议不管项目大小，都要封装一个request工具类，统一处理baseURL、请求头、超时时间、响应拦截器。这里有一个面试必问的点：登录态如何保存？我用的是token方案——用户登录成功后，后端返回一个token，前端把它存到localStorage里，之后每次请求在Axios请求拦截器里把token塞进header的 Authorization 字段。后端有一个拦截器或过滤器，对除了登录、注册之外的接口做token校验。

对应的路由守卫，在Vue Router里通过全局前置守卫处理：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.path === '/login') {
    next()
  } else {
    if (!token) {
      next('/login')
    } else if (to.meta.role && to.meta.role !== store.state.userInfo.roleType) {
      next('/403')
    } else {
      next()
    }
  }
})

这个方案看起来完整，但答辩时有一个高频追问：“前端路由守卫生效了，如果别人直接绕过前端，用Postman请求后端接口怎么办？”这就需要你后端接口做权限校验——根据token解析出当前用户的角色，在Controller层判断是否有权访问该接口。SSM项目可以用SpringMVC的HandlerInterceptor来实现，也可以用注解+AOP实现自定义权限注解。我建议用拦截器，因为代码量少、容易理解、论文好写。

另外，vue devtools 插件值得花时间装上。调试网络请求和响应式数据状态，没有它简直是盲人摸象。如果你用的Chrome商店打不开，可以从镜像站下载crx安装，虽然听起来很基础，但每年都有同学因为浏览器无法调试浪费大量时间。

4.3 列表、表单、视频播放与图表展示：联调中的高频踩坑场景

联调阶段是BUGl最多的阶段。从经验看，集中在以下几个方面：

第一个坑是时间格式问题。后端的LocalDateTime传到前端变成一串数字或者2026-01-01T12:00:00这种ISO格式，前端表格显示不友好。解决方案在后端统一配置JSON序列化格式，SpringMVC可以配置Jackson的 ObjectMapper，或直接在字段上加 @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。前端如果拿到的还是不对劲，用dayjs处理一下。

第二个坑是列表的全选按钮。培训管理后台经常有批量审核、批量删除，el-table里的全选checkbox看似简单，但和分页一起用时，很容易出现“跨页选中”被清空的问题。解决方式是配合 @selection-change 事件维护一个选中的id数组，而不是每次翻页后依赖当前页的selection。el-table的文档里提供 reserve-selection 属性支持跨页选中，用上这个属性之前，必须在el-table-column上设置 row-key，否则控制台全是警告。这个小细节在答辩演示“批量审核”时特别容易露怯。

第三个坑是下拉框远程搜索与滚动加载。如果课程分类数量大，或者学员列表很多，el-select的远程搜索是一个亮点功能。但 remote-method 时要注意防抖，否则每敲一个字母就发一次请求，后端日志会被刷屏。实现防抖可以手写，也可以用lodash的 debounce。下拉滚动加载更多，监听select的滚动事件，在滚动到底时 append 下一页数据，这些都是加分项，但写的时候要注意别把已选中的值覆盖了。

第四个坑是培训视频进度记忆的前后端协作。如果前端用video.js播放，暂停时记录 currentTime，通过接口上传到后端，下次打开视频时再拉取进度续播。这个功能不难，但前端要监听的事件比较多(timeupdate、loadedmetadata、play等)，而且播放器销毁时要及时清理监听器，否则会出现“第一次打开正常，第二次打开视频组件反复触发接口”的问题。这里特别符合热搜词里的“vue播放m3u8”场景，如果源视频转成了m3u8，而你的播放器用的是原生video标签，大概率无法播放，一定要引入hls.js。hls.js的方案是：

javascript复制if (Hls.isSupported()) {
  var hls = new Hls({ xhrSetup: function(xhr, url) {
      xhr.withCredentials = false;
  }});
  hls.loadSource(videoUrl);
  hls.attachMedia(videoEl);
  hls.on(Hls.Events.MANIFEST_PARSED, function() {
      videoEl.play();
  });
} else if (videoEl.canPlayType('application/vnd.apple.mpegurl')) {
  videoEl.src = videoUrl;
}

5. 论文怎么写得像做了很多工作：材料组织与图表制作经验

5.1 论文结构的黄金比例与常见水分点

论文框架一般是：绪论（选题背景、国内外现状、研究内容）、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。很多同学写出来像流水账，问题在于每章篇幅严重失衡，尤其技术介绍部分动辄写四五千字，全是网上抄来的框架概念，导师一眼就能看出来。

我的建议是控制比例：绪论15%、技术介绍10%、需求分析20%、系统设计25%、系统实现20%、测试与总结10%。这个比例的核心思路是——把重点放在“需求分析”和“系统设计”上，因为这才是体现你独立思考和工程能力的地方，技术介绍只是背景铺垫，哪怕写得再华丽也是别人的东西。

论文最容易出现的水分点有三个：一是大段粘贴框架官方文档，比如“Spring是一个轻量级开源框架……”这种话写一页也没用，要用一两句话说清楚自己项目中哪些地方用了Spring的什么特性；二是画图不规范，用例图、ER图、时序图内容与系统实际功能对不上，这一点答辩老师很容易抽查；三是测试章节写“运行结果如图3-1所示”，但截图里没显示系统时间、操作人、关键数据，看起来像从别处贴的。

5.2 需求分析、用例图、ER图、时序图该怎么画才不像凑数

需求分析是论文的根基。这部分要把3.1节提到的三类角色和四个功能模块展开，用表格列出每个模块的用例描述，包括用例名称、参与者、前置条件、基本流程、异常流程。比如“学员报名”用例和“管理员审核报名”用例都要写完整。用例图可以用PowerDesigner或Visio画，但不要在用例图上画太多冗余关系，重点突出系统边界、角色和主要用例。

ER图最好结合我的表设计部分来画。画出实体、属性、实体间关系（1对多、多对多）。比如“课程”和“班级”是1对多，“班级”和“学员”是多对多，通过“报名表”关联。如果只画实体和几条线，会显得太空；如果每个实体的每个属性都画上去，又太挤。我习惯的做法是：ER图上只画核心字段，完整字段列表放在“数据库设计”章节的表格里，这样既清晰又丰富。

时序图重点画几个核心业务，比如用户登录认证流程、报名审核流程。画时序图时要注意消息线的顺序和返回值的标注，很多同学的时序图只有请求没有返回，看起来是断的。例如报名操作，前端点击报名 → Controller接收请求 → Service校验班级人数 → Mapper插入报名记录 → Service返回结果 → Controller返回Result → 前端提示“报名成功”。这条线画清楚，再配合代码里的事务说明，就显得非常专业。

5.3 程序代码截图与关键代码展示的选取原则

论文里的代码不是越多越好，粘贴几百行代码只会让论文变得冗长。重点代码选3~5个典型场景即可：一个是动态SQL多条件查询体现MyBatis的灵活，一个用事务注解实现报名操作体现Spring事务管理，一个是Axios拦截器配合token实现前后端分离的权限控制，一个用hls.js播放m3u8体现你处理非结构化数据的能力。每个代码片段配上文字说明“为什么这么写”，以及“这段代码解决了什么问题”。这种“代码+设计理由”的写法，比单纯贴一堆代码更能得高分。

6. 部署、演示与答辩：最后一周的冲刺安排

6.1 本地部署与打包发布流程

毕设答辩前，先把环境跑通。建议准备一套“演示环境清单”：JDK版本、Maven版本、Redis（如果用了）、MySQL版本、Node版本，并写在论文附录或部署文档里。答辩现场如果临时换电脑，这套清单能帮你快速恢复环境。

前端打包用 npm run build，Vite默认会生成dist目录。如果你用Nginx部署，在nginx.conf里配置一个server块，root指向dist，location /api代理到后端Tomcat地址。这里有个常见问题：前端用 history 模式的路由时，刷新二级页面会404，需要在Nginx里配置：

nginx复制location / {
    try_files $uri $uri/ /index.html;
}

这个细节在论文“系统部署”一节写出来，绝对是一个加分点，因为很多学生的部署章节就是几个截图加“完成”两个字。后端SSM项目打成war包发布到Tomcat的webapps下，或者用Maven打成jar包时，要注意Spring配置文件里数据库连接、文件上传路径等配置需要提取到外部。不需要用Docker，但如果能写个Dockerfile，会让论文的“系统部署”部分更有层次，我建议学有余力的人加一下。

6.2 演示数据准备与全流程预演

演示环节是让我见过太多人翻车的地方：用户登录后，数据列表是空的，点功能也是空的，全场沉默。解决这个问题只有一个办法——提前准备好一套完整的演示数据。比如管理员账号里要有3~5门课程，每门课下面有2~3个班级，班级里要有10~20个学员用户，成绩表要有几十条数据，而且这些数据要互相匹配，不能出现“登录学员后查不到自己报的课程”。

预演时，先把整个系统的演示脚本写下来：从管理员登录，到创建课程、创建班级、审核报名；再切到学员账号，浏览课程、报名、查看成绩；最后切到讲师账号，维护成绩。把每一步点击的位置、预期页面变化、可能出现的异常情况都写清楚。如果有条件，做一次“模拟答辩”的预演，让同组同学扮演老师，随机打断你问问题。这个方法听起来简单，但效果远好于背稿。

另外，演示时要关掉无关的浏览器标签页、弹出通知、开发工具的部分窗口。尽量用Chrome的隐身模式打开系统，避免LocalStorage里残留数据污染登录状态。如果是远程答辩，提前确认屏幕共享权限、麦克风设备，并准备一个手机热点作为备用网络，避免现场Wi-Fi抽风。

6.3 老师最爱问的几个问题及应答思路

答辩环节的高频问题其实高度集中，提前准备就行。第一类是关于技术选型：“为什么用SSM而不用Spring Boot？”回答思路：SSM是Spring生态的基础组合，能更清楚体现Spring核心机制，而且学校课程体系以SSM为主线，便于理论与实践对照。同时强调自己了解Spring Boot的starter自动配置，但选择SSM是为了深入底层。

第二类是关于权限安全：“前端路由守卫能拦住什么，不能拦住什么？”答案要体现出你的理解：前端路由守卫只能改善用户体验，防止未登录用户看到页面；真正的安全校验必须放在后端，因为接口是直接对外暴露的，任何请求都可以通过工具模拟发送。然后举自己项目的例子：登录接口放行，其余接口都在拦截器里校验token并解析role。

第三类是关于业务：“如果一个班级的学员人数已满，但并发报名怎么办？”这题考察并发处理。可以从两个层面回答：业务层面先查再插，存在重复报名问题；数据库层面可以对 sign_up 表加班级和用户的联合唯一索引，或者在班级表上引入乐观锁version字段，更新时校验 version，防止超卖。听到这个答案，老师基本不会再追问。

第四类是关于部署：“前端打包后和后端怎么协作？”这个问题在教程里也常见，标准答法：开发环境用Vite代理解决跨域，上线环境用Nginx托管dist目录，并把 /api 路径代理到后端的Tomcat端口，通过 try_files 解决history路由刷新404问题。

还有一类比较灵活：“如果要新加一个‘问卷调查’模块，你怎么设计？”这时最重要的是展示分析的流程：先明确角色和流程，再设计表结构，再写接口，再写页面。把这个思路讲清楚，老师知道你是有工程思维的，而不是只会背代码。

如果你时间充足，建议在论文“总结与展望”里写一个后续优化方向，比如引入Redis缓存热点课程、用RabbitMQ做报名异步通知、用Docker做环境编排。哪怕这些功能没写代码，也能体现你对系统演进的理解。

我最后再分享一个小技巧：把整个系统跑通后，留一天时间什么都不做，专门检查一个问题——换一个全新的浏览器、清空缓存、用不同的网络环境重新走一遍所有流程。因为答辩现场的机器往往不是你自己调好的那台，一切细节（Node版本、浏览器版本、数据库字符集）都可能出问题。只要能在这个陌生环境下完整跑通一遍演示流程，你就赢了一半。这个项目做下来虽然琐碎，但当你看到管理员、讲师、学员三个账号在同一个系统里各司其职，整个培训业务闭环跑起来的时候，那种成就感是实打实的。希望这篇复盘能帮你少走一点弯路，祝你的毕设顺利通过。