实训管理系统这种东西，表面看是个常规的CRUD项目，但真正动手做过的人都知道，核心难点从来不是增删改查，而是“实训”这两个字背后的业务复杂性：一个实训任务从发布、分配到提交、评定、归档，涉及教师、学生、管理员三种角色，还牵扯到分组、批次、成绩统计、附件上传等一堆边角逻辑。前阵子我为某高校信息中心做了一套基于SpringBoot+Vue的实训管理系统，技术栈是SpringBoot 3 + Vue 3 + MyBatis-Plus + MySQL 8，整套源码从设计到落地花了三周左右，期间踩了不少坑，也沉淀了一些能直接复用的经验。这篇就完完整整把项目拆开讲一遍，从需求建模到表结构设计，从核心代码到部署排错，全程干货，适合正在做毕业设计、课设，或者刚接手这类管理系统的开发者参考。
先说清楚这系统到底解决什么问题。实训管理在教学场景里通常极度依赖人工：教师线下发任务、收作业，学生通过微信群或U盘交报告，管理员再手动录入成绩和统计表。这套系统要做的就是把这个流程线上化——管理员维护班级、教师、课程和实训批次，教师创建实训任务并关联班级，学生在线查看任务、提交报告，教师给出评分和评语，所有数据沉淀在MySQL里，按班级、任务、批次多维度汇总统计，导出Excel上报。整个过程里权限是分开的，三种角色各干各的事，互不越权。
接下来我会按项目的真实推进顺序来写：先讲需求分析和模块建模，再讲数据库怎么设计，然后贴核心功能的代码实现，最后是部署上线和排查实录。你拿到这套思路，哪怕不照抄我的代码，也能自己完整搭建一套同类系统。
1. 项目拆解与需求建模：先理清三类角色和业务闭环
1.1 三类角色都有哪些“痛点”
做管理系统的第一件事，不是写代码，而是把用户拉出来过一遍流程。这个系统涉及三类用户，每一类的核心诉求完全不同。
管理员这边，痛点是“不知道实训进行到哪一步了”。班级多、任务多、教师多，一个学期几十个实训任务分散在各个班级里，月底要统计完成率和成绩分布，全靠Excel来回汇总，效率极低。所以管理端的核心功能是做统筹：维护基础数据（班级、学生、教师、课程）、审核实训批次、全局查看所有任务的进度和成绩数据。
教师（也就是实训指导老师）这边的痛点是“发布任务和收作业太麻烦”。以前要准备任务书文档，逐个班级发通知，收上来的报告命名乱七八糟，评分还要手动登记。所以教师端要解决三件事：快速发布实训任务（填时间、选班级、传附件）、在线预览和下载学生提交的报告、按评分标准打分并一键录入评语。
学生这边最直接的需求就是——别让我交U盘，别让我微信传文件。学生端要能看到自己所在班级的所有实训任务，在线提交报告或代码压缩包，提交后能看到评分结果和老师评语。这三个角色凑在一起，就形成了完整的业务闭环：管理员配基础数据 → 教师创建实训任务 → 学生提交成果 → 教师评分 → 管理员统计导出。整个系统的功能模块围绕这个闭环展开就非常清晰了。
1.2 功能模块怎么划分
按角色划分模块是这类系统最稳妥的做法，前后端分离之后，每个模块对应独立的导航菜单和接口前缀。
- 认证模块：登录、登出、JWT鉴权、角色路由控制。用户名+密码登录，登录成功颁发Token，前端根据角色动态渲染菜单，后端用拦截器校验接口权限。
- 学生管理模块（管理员）：学生的增删改查、批量导入（Excel）、重置密码、关联班级。
- 班级/教师/课程管理模块（管理员）：维护基础信息，用于创建实训任务时的关联选择。
- 实训任务模块（教师）：创建任务、设置时间窗口、关联班级、上传附件；任务列表、编辑、删除、归档。
- 实训提交模块（学生）：查看任务详情、提交报告（文本描述+附件）、查看成绩和评语。
- 成绩评定模块（教师）：列表查看提交记录、在线预览报告、打分、写评语、批量导出成绩。
- 统计报表模块（管理员）：班级完成率、任务平均分、学生成绩分布，支持导出Excel。
- 公告模块（管理员/教师）：发布系统公告，学生端首页可见。
这个模块划分方式几乎适用于所有“管理员-教师-学生”模式的校园管理系统，后面做实习管理、毕业设计管理、顶岗实习管理，都能直接套这个思路，只改字段和业务规则就行。
2. 技术选型背后的“为什么”：这套组合怎么选最稳
2.1 为什么是SpringBoot 3 + MyBatis-Plus而不是JPA
说2025最新，技术上得有点“新东西”。SpringBoot 3.x 是个分水岭，底层基于Jakarta EE，必须要JDK 17以上，启动速度比2.x快不少。最重要的是SpringBoot 3内置了GraalVM原生镜像的构建支持，如果要发轻量级部署包，体验会好很多。MyBatis-Plus我用了很长时间，项目里几乎不离手。对比JPA（Spring Data JPA），我个人的感受是：JPA适合实体关系特别复杂、查询需求可以标准化的场景，但遇到多表关联、带条件统计的复杂SQL时，JPQL写起来非常绕，还不如直接写SQL直白。而MyBatis-Plus的逻辑删除、自动填充、分页插件、条件构造器，对这类管理系统的CRUD来说简直就是量身定做，省掉大量样板代码。
这里有个选型教训：第一版我用的是纯MyBatis，所有Mapper的XML都要手写，结果光学生列表的分页查询就写了二三十行XML。后来换到MyBatis-Plus，一个LambdaQueryWrapper加内置分页插件就解决了。如果你是做毕业设计或用这个项目二次开发，MyBatis-Plus能让你把时间留给业务逻辑，而不是耗在SQL上。
2.2 前端Vue 3 + Element Plus怎么配合后端
前端选Vue 3搭配Element Plus组件库，是目前中小型管理系统的主流组合。Vue 3的组合式API配合<script setup>，写业务组件的代码量比Vue 2的选项式API少了三分之一，逻辑复用用useXxx函数抽取就行。Element Plus对表单、表格、弹窗、上传这些后台常见场景支持非常好，一个el-table加几个字段配置就能出列表页。
项目里我用Vite作为构建工具，开发环境用代理解决跨域，生产环境直接构建出静态文件，由后端SpringBoot统一托管。路由用Vue Router，状态管理用Pinia（Vue 3对应的状态库）。Pinia的写法比Vuex简洁太多，直接把用户信息、Token、角色这些全局状态定义成store，组件里调用非常清爽。这里强调一下，新手第一个坑往往是“前端端口3000，后端端口8080，跨域报错”，我在第6节会专门讲怎么配置开发环境和生产环境的跨域，避免上线时才手忙脚乱。
2.3 MySQL 8为什么够用
数据存储选MySQL 8，这个没什么悬念。一是部署成本极低，二是对这种几千条/几万条数据量级的管理系统，性能完全够用。MySQL 8的窗口函数和JSON字段在某些统计场景很有用，比如算每个实训任务的提交率、分布区间，直接一条SQL就能搞定。表结构里如果有需要灵活扩展的字段（比如任务的可选配置项），用JSON类型比拆表更方便。
字符集统一用utf8mb4，排序规则用utf8mb4_unicode_ci，这是为了支持中文和一些特殊字符（比如学生姓名里的生僻字），很多老系统因为用了utf8不带mb4，导致生僻字入库直接报错或者变问号，这点建库时不能省。时区问题也建议提前处理，连接串里加serverTimezone=Asia/Shanghai，否则日期字段在Java和MySQL之间穿梭会出现8小时的时差，我在排查篇里会再提一次。
3. 数据库设计：实训管理系统的表结构怎么建才不返工
3.1 核心表结构总览
表设计直接决定系统能撑多复杂的业务。这个项目的核心表一共8张，我会把每张表的定位讲清楚，你建库的时候照着做就行。设计原则很简单：基础数据表与业务数据表分离，业务表之间通过外键ID关联，但不在数据库层面强制物理外键。为什么不加物理外键？加了删除麻烦，后期改数据也麻烦，而且一旦数据量大，外键约束检测会成为热点问题。逻辑关联靠代码控制，这是当前业务系统的主流做法。
| 表名 | 定位 | 关键字段说明 |
|---|---|---|
| sys_user | 用户表 | id, username, password, real_name, role, class_id |
| sys_role | 角色表 | id, role_code, role_name（虽然用枚举也可以，但独立出来权限扩展方便） |
| edu_class | 班级表 | id, class_name, grade, major |
| edu_course | 课程表 | id, course_name, course_code |
| tr_task | 实训任务表 | id, title, content, course_id, teacher_id, start_time, end_time, status |
| tr_task_class | 任务班级关联表 | id, task_id, class_id |
| tr_submission | 实训提交表 | id, task_id, student_id, content, file_url, score, comment, submit_time |
| notice | 公告表 | id, title, content, publisher_id, create_time |
这里重点说tr_task_class这张关联表。一个实训任务可以下发给多个班级，一个班级有多个任务，这属于典型的多对多关系，必须有中间表。很多人做多对多时偷懒，直接在任务表里写一个class_ids字段用逗号分隔，这看起来很省事，但你后面要做“按班级统计任务数”的需求就痛苦了，SQL根本没法高效地关联查询。我的建议是：管理系统中牵涉多对多关系的，一律建中间关联表，不要图省事。
3.2 实训任务和提交表的状态机设计
状态设计是这套系统的灵魂。实训任务的状态我用了四个：0草稿、1进行中、2已结束、3已归档。教师在创建任务时先存草稿，确认设置无误后点击发布，状态变为进行中；到达截止时间后，系统自动（或管理员手动）置为已结束；学期结束后归档，归档后学生端不再显示。
实训提交表的评分状态我用了三个：0未评分、1已评分，外加一个可选的状态2已退回（打回让学生修改后重新提交）。退回功能是我在第一版时没做，后来被老师吐槽“学生交错了文件没法处理”才补上的。这个设计提醒我：状态字段一定要预留，宁可先用0和1，也不要一开始就扣死。
字段设计上有个小细节——tr_submission表里加了submit_count字段记录学生的提交次数。为什么需要？因为老师评分时想看到这个学生是第几次提交，频繁提交修改的说明态度认真，只交一次的可能是赶工。这个字段不复杂，但实用价值很高，属于“在需求文档里没写，但做着做着就觉得必须有”的典型。
3.3 索引怎么建才科学
索引设计遵循“查询频率优先”原则。实训任务表、提交表是最热的两张表，索引一定要建到位。
tr_task(teacher_id, status)：教师查自己的任务列表，状态过滤。tr_task(start_time, end_time)：时间范围查询和自动归档定时任务会用到。tr_submission(task_id, student_id)：唯一索引，防止同一学生对同一任务重复提交。这里用了联合唯一索引，代码层面也做了校验，双保险。tr_submission(task_id, score)：成绩统计和列表排序用。
有一个真实的反例：前几版我在tr_submission表上没有加task_id + student_id的唯一索引，结果有学生短时间内双击提交按钮，生成了两条提交记录，评分时老师看到两个记录非常疑惑。后来加了唯一索引，又在后端接口做了“提交前校验当前任务是否已提交”的逻辑，才算彻底堵上这个漏洞。数据库层面的约束永远是最后一道防线，代码逻辑也要跟上。
4. 核心功能实现与关键代码拆解
4.1 登录认证：JWT + 拦截器的经典组合
认证方案选JWT（JSON Web Token），因为前后端分离项目用Session天然不方便——前端部署的静态资源和后端接口分离，Session没法跨域维持，而JWT把用户身份信息加密进Token里，后端无状态校验即可。登录接口流程是：校验用户名密码 → 查询用户角色 → 生成Token返回给前端 → 前端存到Pinia和localStorage → 每次请求头带Authorization: Bearer <token>。
// JWT工具类核心代码 @Service public class JwtUtil { private static final String SECRET = "your-256-bit-secret-key"; private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000; // 24小时 public String generateToken(Long userId, String username, String role) { Date now = new Date(); Date expireDate = new Date(now.getTime() + EXPIRE_TIME); return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }拦截器这块有个细节要说明：SpringBoot 3里常用的拦截器还是HandlerInterceptor，但注册方式有一点变化，需要通过WebMvcConfigurer注册，同时因为JWT校验只需要在非登录接口上生效，所以登录接口要在拦截器配置时排除掉。否则会出现“登录接口自己也被拦截”的循环问题。
注意：在实际项目中，拦截器校验Token后，要把解析出来的用户信息塞到
ThreadLocal或请求属性里，方便后续Controller获取当前用户。不能用request.getParameter("userId")这种方式获取，前端传过来的参数不可信，必须从Token里取。
4.2 实训任务的创建与时间窗口校验
实训任务是整个系统的核心业务。教师创建任务时，后端要做三重校验：一是当前用户必须是教师角色（角色校验）；二是任务开始时间不能晚于结束时间；三是关联的班级必须存在且可用。
这三个校验里，最容易写漏的是时间校验。我当时就漏了“结束时间必须晚于当前时间”这条，结果教师在页面上把截止时间设为过去的日期，任务刚发布就变成已结束状态，学生都来不及看。代码里加一个简单判断就好了：
// 创建实训任务 public Long createTask(TaskCreateDTO dto) { LocalDateTime now = LocalDateTime.now(); if (dto.getEndTime().isBefore(now)) { throw new BizException("截止时间不能早于当前时间"); } if (dto.getStartTime().isAfter(dto.getEndTime())) { throw new BizException("开始时间不能晚于截止时间"); } TrTask task = new TrTask(); BeanUtils.copyProperties(dto, task); task.setStatus(0); // 草稿 task.setTeacherId(CurrentUser.get().getUserId()); taskMapper.insert(task); // 插入任务和班级的关联 dto.getClassIds().forEach(classId -> { TrTaskClass tc = new TrTaskClass(); tc.setTaskId(task.getId()); tc.setClassId(classId); trTaskClassMapper.insert(tc); }); return task.getId(); }发布任务之后还有个很关键的隐藏操作——给关联班级下的所有学生生成一条“待办通知”。这个我在第一版没做，后来老师反馈“学生根本不知道有新任务”，才意识到：系统里不能靠学生主动刷新页面发现任务，必须由系统在任务发布时主动通知。实现方式有两种：一种是发布时批量插入消息记录表，学生登录后查询；另一种是发布后把任务ID推送到学生的“我的任务”缓存表。普通量级下用前者就够了，一个班级50人，三个班150条消息，MySQL插入毫无压力。这个环节做得好，整个系统的体验会提升一个档次。
4.3 学生提交报告：文件上传服务的边界设计
学生提交实训报告，界面是文本域加附件上传。文本域存内容简介，附件存实际报告文件。文件上传我单独做了一个FileController，统一接收文件和业务模块分流，好处是所有上传文件都走同一个逻辑，后续做文件类型限制、大小限制、改名策略，只改一处就行。
@RestController @RequestMapping("/api/file") public class FileController { @Value("${file.upload-dir}") private String uploadDir; @PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); // 防止文件名重复：UUID + 后缀 String newFilename = UUID.randomUUID().toString().replace("-", "") + ext; File dest = new File(uploadDir + "/" + newFilename); try { file.transferTo(dest); return Result.success("/files/" + newFilename); } catch (IOException e) { return Result.error("文件存储失败"); } } }这里必须强调几点：文件名一定要重命名，不然两个学生都传报告.docx，后传的会覆盖先传的，这个坑我踩过，真实损失了一个学生的报告数据。上传路径建议配置成外部绝对路径，比如Windows下的D:/files，Linux下的/data/files，不要放在项目目录内——项目重新部署打包时，本地存储的文件可能被清掉。
4.4 成绩评分与统计：SQL怎么写才高效
教师评分后，成绩要实时反映在统计报表中。管理员端的统计页面需要显示：每个任务的提交率、班级平均分、优秀/良好/及格/不及格四档分布、总分排名。这些统计可以用几条SQL完成，关键是用好聚合函数和条件表达式。
-- 统计某班级在某课程下所有任务的平均分和提交率 SELECT t.id AS task_id, t.title AS task_title, COUNT(s.id) AS submit_count, COUNT(s.id) / (SELECT COUNT(*) FROM edu_student es WHERE es.class_id = #{classId}) AS submit_rate, ROUND(AVG(s.score), 1) AS avg_score FROM tr_task t LEFT JOIN tr_task_class tc ON t.id = tc.task_id LEFT JOIN tr_submission s ON t.id = s.task_id WHERE tc.class_id = #{classId} AND t.course_id = #{courseId} GROUP BY t.id, t.title;注意这里的LEFT JOIN，因为任务是主表，提交记录是副表——有的任务可能就是没人提交，但统计时也要显示出来，用LEFT JOIN保证任务记录不丢失。如果用INNER JOIN，没提交的任务就消失了，统计报表就会漏项。这种细节在写报表SQL时最容易被忽略。
统计模块还有一个绕不开的地方——成绩分档统计。我用MySQL的CASE WHEN一次性算出来，不需要在Java里循环遍历：
SELECT SUM(CASE WHEN score >= 90 THEN 1 ELSE 0 END) AS excellent, SUM(CASE WHEN score >= 80 AND score < 90 THEN 1 ELSE 0 END) AS good, SUM(CASE WHEN score >= 60 AND score < 80 THEN 1 ELSE 0 END) AS pass, SUM(CASE WHEN score < 60 THEN 1 ELSE 0 END) AS fail FROM tr_submission WHERE task_id = #{taskId};4.5 前端关键页面的实现方案
前端这边，最有代表性的页面是教师的实训任务列表页和学生端的任务提交页。任务列表页用Element Plus的el-table加筛选表单，分页用el-pagination，状态字段映射为标签显示。
<!-- 实训任务列表页核心模板结构 --> <template> <div class="task-list"> <el-form :inline="true" :model="queryForm"> <el-form-item label="任务名称"> <el-input v-model="queryForm.title" placeholder="输入关键词" clearable /> </el-form-item> <el-form-item label="状态"> <el-select v-model="queryForm.status" placeholder="全部"> <el-option label="草稿" :value="0" /> <el-option label="进行中" :value="1" /> <el-option label="已结束" :value="2" /> <el-option label="已归档" :value="3" /> </el-select> </el-form-item> <el-form-item> <el-button type="primary" @click="loadTasks">查询</el-button> <el-button @click="resetQuery">重置</el-button> </el-form-item> </el-form> <el-table :data="taskList" v-loading="loading" border> <el-table-column prop="title" label="任务名称" min-width="180" /> <el-table-column prop="courseName" label="关联课程" width="120" /> <el-table-column prop="className" label="关联班级" width="180" /> <el-table-column prop="startTime" label="开始时间" width="180" /> <el-table-column prop="endTime" label="截止时间" width="180" /> <el-table-column label="状态" width="100"> <template #default="{ row }"> <el-tag :type="statusType[row.status]">{{ statusText[row.status] }}</el-tag> </template> </el-table-column> <el-table-column label="操作" width="200" fixed="right"> <template #default="{ row }"> <el-button size="small" @click="gotoDetail(row.id)">查看</el-button> <el-button size="small" type="primary" v-if="row.status === 0" @click="publishTask(row.id)">发布</el-button> </template> </el-table-column> </el-table> <el-pagination v-model:current-page="queryForm.pageNum" v-model:page-size="queryForm.pageSize" :total="total" layout="total, prev, pager, next" @current-change="loadTasks" /> </div> </template>学生端的提交页比较有意思，因为有唯一索引限制“一人一任务只能交一次”，前端提交时要做二次确认，提示“提交后无法修改，是否确认提交”。同时支持老师在已评分后选择退回，退回后学生端状态变为“已退回”，此时可以修改并重新提交——这个状态机的联动是前端交互里最容易出bug的地方，代码里要严格根据scoreStatus的值渲染不同按钮。
5. 部署上线与常见问题排查实录
5.1 从开发到上线的环境准备清单
无论你是在Windows上开发还是在Linux服务器上部署，环境版本建议统一如下。这套组合我实际跑过很多次，兼容性最稳：
| 组件 | 版本建议 | 说明 |
|---|---|---|
| JDK | 17 或 21 | SpringBoot 3 必须 JDK 17+，LTS版本优先 |
| Maven | 3.8+ | 构建后端项目 |
| Node.js | 18 LTS 或 20 LTS | 构建Vue3前端 |
| MySQL | 8.0+ | 生产环境建议8.0.28以上 |
| Redis | 不用也行 | 本项目没引入Redis，如果后续做验证码、消息队列，再考虑 |
如果你用的是JDK 8，那SpringBoot 3直接跑不起来，别挣扎，老老实实换JDK 17。另外前端Vue 3项目用Vite构建后，产物在dist目录，部署时把dist里的内容放到Nginx的html目录下，或者直接让SpringBoot托管。
5.2 后端打包与前端部署
后端打包用Maven，执行mvn clean package即可，产物是一个可执行jar包。启动命令建议加JVM参数指定内存：
nohup java -jar -Xms256m -Xmx512m training-system.jar > app.log 2>&1 &-Xms和-Xmx分别指定初始堆内存和最大堆内存，对于这种中小系统512M完全够了。不加参数直接用默认值的话，在某些限定内存的云服务器上会被直接杀掉。前端部署比较简单，npm run build后用Nginx托管dist目录，配置一下反向代理即可。
Nginx的配置是一个高频坑点。开发时前端用Vite代理转发接口，上线后Nginx也必须配置对应的反向代理，否则前端请求/api会404：
server { listen 80; server_name your-domain.com; root /var/www/training-web; index 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; } location /files/ { alias /data/files/; } }这段配置里，location /api/把前端的接口请求转发到后端8080端口，location /files/把上传文件的访问路径映射到服务器上实际存储文件的目录。两个location配置是最容易漏的，漏了前端页面能打开但接口全挂，或者图片/附件点开全404。
5.3 部署和开发期最常见的异常排查
（1）数据库连接串时区问题。现象是前端页面数据显示的时间比真实时间慢了8小时。原因：JDBC连接串没有指定时区，MySQL和Java的时区解释不一致。解决：连接串加serverTimezone=Asia/Shanghai和useSSL=false。
（2）大文件上传失败。SpringBoot默认单文件上传上限是1MB，实训报告动辄十几MB，必须手动调大配置：
spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB这个配置不调，前端传大报告时会出现“上传失败 413”或者后端直接抛异常。另外Nginx位置如果有client_max_body_size限制，也要一并调大，否则Nginx层就把请求拦了。
（3）MyBatis-Plus的字段映射空格问题。如果你的数据库字段用下划线命名（比如class_id），而实体字段是驼峰（classId），正常情况下MyBatis-Plus会自动映射，但前提是mapUnderscoreToCamelCase开启。SpringBoot的配置中这个值默认是true，但如果你的yaml里手动改了全局配置，要确认没有覆盖为false。我曾经因为这个配置被覆盖，导致所有关联查询的字段全是null，排查了整整一个下午。
（4）前端跨域问题。开发期前端在localhost:5173，后端在localhost:8080，浏览器的同源策略会拦截请求。两个解决办法：一是前端Vite配置代理，这个最推荐，因为上线后由Nginx统一转发，没有跨域问题；二是后端配置CORS全局允许，适合临时测试。
// vite.config.js 开发代理配置 export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })配置之后，开发时前端直接请求/api/xxx，Vite会转发到后端，浏览器层面看不到跨域，改动只需要在前端配置文件里完成。
5.4 设计上容易踩的几个业务坑
这里集中说几个我反复遇到的问题，每个都是真实教训：
（1）学生提交附件没有格式限制。学生上传了一个.exe文件，差点让IT部门以为是病毒。后来在文件上传接口加了一层扩展名白名单校验，只允许.doc/.docx/.pdf/.zip/.rar/.jpg/.png/.xlsx。白名单校验本质是if判断扩展名，但要注意做大小写处理，否则.PDF会被拦截。
（2）自动归档没有定时任务。实训任务截止时间过了，状态还停留在“进行中”，学生端还能提交。后来加了一个SpringBoot的@Scheduled定时任务，每小时扫描一次，把截止时间早于当前时间并且状态为“进行中”的任务自动置为“已结束”。定时任务这个功能在第一次开发时非常容易被漏掉，但老师说“线上系统不可能每天手动去改状态”，所以这一步必须做。
@Component public class TaskStatusScheduler { @Scheduled(cron = "0 0 * * * ?") // 每小时执行一次 public void autoFinishTasks() { taskMapper.autoFinishExpiredTasks(LocalDateTime.now()); } }（3）删除任务没有软删除保护。管理员误删了某个实训任务，连带提交记录全部没了，数据无法恢复。后来所有表的主删除逻辑统一改成MyBatis-Plus的逻辑删除，delete变成update deleted = 1，查询会自动过滤。逻辑删除字段虽然多一条数据，但安全性大幅提升。
（4）成绩修改没有操作日志。老师修改了一次评分，没有任何记录，学生质疑“分数不对”时无从查起。解决方案是加了一张score_log表，每次评分或改分时插入一条记录，记录操作人、操作时间、原分数、新分数。成本很小的一个表，但对公信力帮助很大。这种日志表是这个项目里最值钱的隐形需求。
6. 这套系统还能怎么扩展
实训管理系统做完之后，我很快就发现它的骨架可以用在很多类似场景里。代码层面做少量改动就能扩展出：
- 实习管理系统：实训任务改成“实习周记”，指导教师改成“企业导师”，提交报告改成“周记打卡+实习鉴定表”。
- 毕业设计管理系统：实训任务改成“设计选题”，提交改成“开题报告+中期检查+毕业论文”，评分改成“交叉评审”。
- 竞赛管理系统：教师端改成“赛事发布”，学生端改成“报名+作品提交”，评分改成“多评委打分取平均”。
这个项目本身的价值不只是一套可运行的代码，更重要的是它把“角色权限-任务发布-提交评审-统计报表”这套业务范式沉淀了下来。往后遇到类似的校园管理场景，你只需要替换实体字段和业务流程细节，架构层面基本不用动。这就是为什么我一直建议开发者多拆解这类系统——业务范式理解了，换任何领域都能快速上手。
7. 最后的几点实操体会
文章写到最后，我聊几句实在话。这项目从需求确认到正式交付，最有价值的不是代码量，而是几轮和实际用户（老师、学生、教务管理员）的反复沟通。很多细节是纸上谈兵时根本想不到的，比如任务截止后学生还能不能提交？提交后老师能不能退回？退回后学生能不能再交？这些状态机问题，面试时你背得再熟，不亲手做一遍是体会不到其中微妙之处的。
如果你打算用这套源码做毕业设计或者二次开发，我建议不要直接跳到改功能，先花半天把表结构和接口文档过一遍，再把登录到评分的主流程跑通，最后再加自己的个性化需求。这样做的好处是，出了问题你知道去哪里排查，而不是在自己不熟悉的代码里瞎试。排错时优先看日志，后端日志文件里异常信息是最直接的线索，前端的问题用浏览器开发者工具看Network面板和Console面板，别急着改代码。
最后分享一个小技巧：这个系统的表结构和核心接口设计我放在本地的笔记里，每次接类似的校园管理系统项目，直接复制一份改一改就能用。三周的项目，第二周就能跑通主流程，剩下时间全在打磨细节。经验和范式的积累，比多写一万行代码更有意义。
