企业官网建设流程全解析

医学电子技术课堂系统从零到交付：Spring Boot + Vue 全栈实战复盘

说出来你可能不信，医学电子技术这门课的教学管理，很长一段时间都是靠 Excel 和微信群撑着的。课程资源散落在各个网盘链接里，实验报告用纸质版提交再手工登记分数，课堂测验印在纸上，波形识别图一复印就糊成一片。我接到这个基于 Spring Boot + Vue 的医学电子技术课堂管理系统项目时，甲方老师的原话是：“年年这么整太累了，能不能把上课前、上课中、上课后所有杂事装进一个系统里。”

这篇文章是我完整做完这套系统后的实战复盘。从需求推导、技术选型、模块拆解，到医学课程场景里特有的坑、数据库设计的三次返工、以及最后源码在本地跑通的完整步骤，都会讲到。无论你是准备做毕设、想给自己的课程搭一套管理系统，还是单纯想看看一个 Spring Boot + Vue 管理端项目从 0 到 1 是怎么落地的，这篇都值得花几分钟读完。

1. 医学电子技术课的教学现场：一堂课背后的管理账本

1.1 这门课的课程结构：理论、实验、测验三线并行

医学电子技术是生物医学工程、医学影像技术、临床工程等专业的基础核心课。课程内容覆盖生物电信号的产生与采集、前置放大器设计、滤波电路、心电/脑电/肌电信号的测量处理，以及各类医用电子仪器的原理认知。

这类课程有一个鲜明特点：教学环节不是“老师讲、学生听、期末考”这么简单，而是三条线并行推进。

• 理论线：课件、讲义、电路原理图解析，需要老师上传资料、发布公告，学生课后预习复习。
• 实验线：学生要在实验室搭电路、接电极、测波形，最后形成一份包含数据截图、波形图、分析结论的实验报告。这份报告要交、要批改、要打分、要退回来修改重交。
• 测验线：除了期末考，还有大量随堂小测和单元测验。医学电子技术里很多知识点是波形识别和定量计算，必须靠频繁的客观题测试来巩固。

三条线的数据最终都要汇入总评成绩。而总评又通常不是简单的“期末考 70% + 平时 30%”，而是实验报告、考勤、随堂测验、作业、期末考各占不同权重。这套逻辑用 Excel 手工维护，到了学期末就是一场灾难。

1.2 过去“Excel + 微信群”模式到底卡在哪

我花了一周时间去旁听这位老师的课，也翻了他过去几年的教学记录，把原有模式的问题总结成了一张痛点清单。

最让我印象深刻的是一次成绩登分事故：两个学生的姓名相似，实验报告分数在 Excel 里填串了行，直到期末总评公布后学生找过来才发现。这种问题在纸质 + 表格的流程里几乎是必然发生，不是老师不细心，而是这套流程本身就没有校验机制。

1.3 从痛点推导出来的功能需求清单

旁听结束后，我拉着老师把整个学期的教学动作用用户故事的方式过了一遍。所谓“用户故事”，就是描述“谁在什么场景下需要什么操作、解决什么问题”。这样推导出来的功能清单才有据可依，而不是拍脑袋想功能。

最终确定的核心需求分成五个模块：

• 用户与权限：学生、教师、管理员三种身份，各自登录后看到不同的工作台界面。
• 课程与资源中心：课程信息展示、章节目录维护、课件上传与在线预览、课程公告发布。
• 课堂互动：扫码签到、随堂测验、课件浏览记录统计。
• 实验报告管理：报告模板下载、在线提交、教师批改打分、退回修改的完整闭环。
• 成绩中心：多维度成绩登记、按权重自动汇总总评、成绩分布可视化。

功能列表不长，真正做起来却有非常多细节要抠。下面从技术选型开始讲，因为技术方案直接决定了后面这些功能落地的效率和坑的数量。

2. 技术选型的真实理由：Spring Boot 搭后端、Vue 画界面的取舍

2.1 为什么后端用 Spring Boot 而不是其他方案

后端选择 Spring Boot，几乎不需要犹豫。原因有三。

第一，生态成熟度。课堂管理系统本质上是一个典型的 CRUD 密集型中后台应用，涉及用户管理、课程管理、文件上传、报表统计。这套东西在 Java 生态里有大量现成解决方案，遇到问题 Stack Overflow 上一搜一大把，开发效率和学习成本都在可控范围内。

第二，约定大于配置。Spring Boot 的起步依赖（Starter）机制把繁琐的配置封装掉了。我需要 MySQL 就把spring-boot-starter-data-jpa或 MyBatis-Plus 的依赖加进来，需要权限认证就集成 JWT，需要文件上传就在配置里写一个上传路径。项目从零初始化到能跑起来，半小时以内可以完成。

第三，部署简单。后端最终打成一个 JAR 包，java -jar直接跑。对实验室或老师个人来说，不需要额外装 Tomcat、配 Nginx，一个 JDK 环境就够了。这种“一键部署”的特性在校园网环境下非常重要。

具体到持久层框架，我这个项目用的是MyBatis-Plus而不是原生 MyBatis 或 JPA。原因很实际：MyBatis-Plus 的BaseMapper提供了绝大多数单表 CRUD，配合分页插件和逻辑删除功能，写代码速度极快。而且它支持在 XML 里手写复杂 SQL，成绩统计、考勤率计算这类多表关联查询完全不会被框架卡住。

2.2 为什么前端选 Vue：工程化之后的开发效率

前端从 React 和 Vue 里选了 Vue，理由同样实在。

Vue 的学习曲线比 React 平缓。对于要快速交付的项目来说，团队里哪怕有人第一次写 Vue，靠着官方文档和 Element UI 组件库也能一天内上手。课堂管理系统页面多但交互复杂程度有限，绝大多数页面就是列表、表单、弹窗、树形菜单这几种形态的组合，Vue 的单文件组件写起来非常直观。

这个项目选的是Vue 2 + Element UI + Vue CLI 3这个组合。放在今天看可能不是最新，但它是目前中文技术社区里教程最多、踩坑记录最全的搭配。Spring Boot 2.x + Vue 2 这个经典组合最大的优势是稳——npm 包里几乎没有破坏性变更，装完依赖就能跑，特别适合毕业设计和课程项目这种“必须在规定时间内跑起来”的交付场景。

顺带说一句，如果你自己开新项目，Vue 3 + Vite + Element Plus 是更好的选择。但如果你拿到的源码是 Spring Boot + Vue 2 这套组合，不需要强行升级，先用起来再说。

2.3 前后端分离的架构设计：部署方式与目录组织

整个系统采用前后端完全分离的结构。后端只提供 RESTful API，返回 JSON 数据；前端用 Vue 路由管理页面，通过 Axios 调用后端接口。两者通过 Token 做身份认证。

后端目录按经典分层组织：

src/main/java/com/example/mededu ├── controller // 接收请求、返回响应 ├── service // 业务逻辑层 ├── mapper // MyBatis-Plus 数据访问层 ├── entity // 数据库实体类 ├── config // 跨域、拦截器、MyBatis-Plus 分页插件配置 ├── common // 统一返回结果、异常处理、工具类 └── MedEduApplication.java // 启动类

前端目录：

src ├── api // 按模块拆分的 Axios 接口封装 ├── views // 页面组件，一个路由对应一个页面 ├── components // 可复用组件（上传组件、富文本编辑器等） ├── router // Vue Router 路由表 ├── store // Vuex 状态管理（token、用户信息） └── utils // 请求拦截器、时间格式化等工具

接口设计遵循 REST 风格：资源用名词、操作用 HTTP 方法。比如POST /api/experiment-report表示提交实验报告，PUT /api/experiment-report/{id}表示导师修改批改结果，GET /api/experiment-report?studentId=xxx表示查询某个学生的报告列表。这种设计不需要额外的接口文档，看一眼 URL 就知道在操作什么资源。

2.4 为什么不建议在中小型课堂系统上微服务

坦白说，我看到不少学生项目一上来就拆微服务：用户服务、课程服务、网关、注册中心。然后光配置 Nacos 和解决服务间调用的网络问题就花了两周。

这个项目的业务复杂度完全没到需要微服务的程度。一套单体应用，内部按业务模块划分好 package 边界，足够应对几百上千人的课堂规模。单体应用在测试、部署、调试上的成本都低得多——直接在 IDEA 里启动，断点一打，前后端联调，非常顺畅。

如果担心后期扩展，正确做法是在单体内部做好模块边界。比如把用户、课程、测评相关的 service 分开，未来真要拆服务时按这些边界切分即可。这是业务复杂度驱动的演进，而不是一开始的过度设计。

3. 模块拆解：课程、实验报告、测验与成绩是怎么一一落地的

3.1 课程中心：章节树、课件与公告的数据模型与接口设计

课程中心是整个系统的地基。老师创建课程，维护章节目录，上传课件，发布公告；学生选课后进入课程空间，按章节浏览学习资料。

数据库设计上，课程、章节、课件三类核心表关系如下：

-- 课程表 CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_name VARCHAR(100) NOT NULL, course_code VARCHAR(50) NOT NULL, teacher_id BIGINT NOT NULL, description TEXT, status TINYINT DEFAULT 1 COMMENT '1-启用 0-停用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 章节表，支持多级目录 CREATE TABLE course_chapter ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, parent_id BIGINT DEFAULT 0 COMMENT '0 表示一级章节', chapter_name VARCHAR(200) NOT NULL, sort_order INT DEFAULT 0 ); -- 课件资源表 CREATE TABLE course_file ( id BIGINT PRIMARY KEY AUTO_INCREMENT, chapter_id BIGINT NOT NULL, file_name VARCHAR(255) NOT NULL, file_url VARCHAR(500) NOT NULL, file_size BIGINT, file_type VARCHAR(20), upload_time DATETIME DEFAULT CURRENT_TIMESTAMP );

章节采用parent_id自关联的无限级分类设计，一级章节下面是二级小节，前端用 Element UI 的el-tree组件渲染成树形菜单。上传文件时用 UUID 重命名保存到本地磁盘或者 OSS，数据库只存逻辑文件名和访问路径。

接口上比较关键的是章节树接口：

@GetMapping("/api/course/chapter/tree/{courseId}") public Result<List<ChapterNode>> getChapterTree(@PathVariable Long courseId) { // 查询该课程下所有章节，按 parent_id 组装成树形结构 List<CourseChapter> chapters = chapterService.list( new LambdaQueryWrapper<CourseChapter>() .eq(CourseChapter::getCourseId, courseId) .orderByAsc(CourseChapter::getSortOrder) ); return Result.success(buildTree(chapters, 0L)); }

课件支持在线预览是老师非常看重的功能。PDF 课件直接用浏览器打开没问题，但 PPT 课件需要先转成 PDF 才能在线预览。这个项目对常见课件统一建议老师上传 PDF 版本，服务器端做的转换逻辑相对简单，只处理了 PDF 和图片文件的预览，避免引入 Office 转换组件增加部署难度。

3.2 实验报告闭环：从模板下载到教师评分的状态机设计

实验报告管理是这套系统里业务状态最复杂的模块。医学电子技术实验报告不是一次交完就结束了，而是有“提交—批改—退回—再提交”的往复过程。

我把它设计成一张带状态字段的业务表，用状态机管理整个生命周期：

其中退回操作是医学类实验报告特有的需求。很多医用仪器的实验报告里，波形截图不标准、结论分析不到位，老师需要打回重做。状态机设计里“退回”之后要允许学生重新提交，但保留历史批改记录，这样老师能看到学生修改前后的对比，判断是否认真订正。

核心表结构：

CREATE TABLE experiment_report ( id BIGINT PRIMARY KEY AUTO_INCREMENT, experiment_id BIGINT NOT NULL COMMENT '实验项目', student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, file_name VARCHAR(255), file_url VARCHAR(500), status TINYINT DEFAULT 0, score DECIMAL(5,2), teacher_comment VARCHAR(1000), submit_time DATETIME, review_time DATETIME );

后端接口设计上，状态流转不做成万能 update，而是拆成语义明确的独立接口：submitReport、reviewReport、returnReport、archiveReport。这样做的坑是联调阶段我会讲到，状态变更的逻辑放在 Service 层做校验，controller 只负责接收参数，避免前端误传状态值把流程打乱。

3.3 在线测验：多题型结构与防刷新计时

在线测验模块要支持单选、多选、判断三种题型，医学电子技术里大量考察波形识别和公式计算，所以题目中需要插入图片，富文本是不可或缺的。

题目和试卷的设计拆成四张表：

-- 题库表 CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, question_type TINYINT COMMENT '1-单选 2-多选 3-判断', question_content TEXT, option_a VARCHAR(500), option_b VARCHAR(500), option_c VARCHAR(500), option_d VARCHAR(500), answer VARCHAR(10) COMMENT '单选题填A/B/C/D，多选填ABD，判断填T/F' ); -- 测验表 CREATE TABLE exam ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, exam_name VARCHAR(200), duration_minutes INT COMMENT '考试时长（分钟）', total_score INT, start_time DATETIME, end_time DATETIME ); -- 测验题目关联表 CREATE TABLE exam_question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, exam_id BIGINT NOT NULL, question_id BIGINT NOT NULL, question_score INT ); -- 学生答题记录表 CREATE TABLE exam_answer_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, exam_id BIGINT NOT NULL, student_id BIGINT NOT NULL, question_id BIGINT NOT NULL, student_answer VARCHAR(10), is_correct TINYINT, create_time DATETIME );

这套设计最大的亮点是防刷新计时。考试倒计时如果完全依赖前端 JS 计时，学生只要刷新页面重开就能重置时间。我的做法是：

• 学生开始答题时，后端记录exam_start_time。
• 前端倒计时显示使用结束时间减去当前服务端时间，剩余时间从后端接口获取。
• 每次提交答案时，后端校验当前时间 > 开始时间 + 考试时长，超时则强制交卷。

核心逻辑：

public Result<ExamResultVO> submitExam(SubmitExamDTO dto) { ExamRecord record = examRecordService.getByExamAndStudent(dto.getExamId(), dto.getStudentId()); if (record == null) { // 首次提交，记录开始时间 record.setStartTime(new Date()); } else { long usedMinutes = (System.currentTimeMillis() - record.getStartTime().getTime()) / 60000; Exam exam = examService.getById(dto.getExamId()); if (usedMinutes > exam.getDurationMinutes()) { // 超时，自动交卷并异常提示 return Result.error("考试时间已到，系统已自动交卷"); } } // ... 批改客观题并写入 answer_record 和总分 }

成绩计算放在服务端而不是前端，这点至关重要。前端的计算只做展示，后端根据题库中预存的答案逐题判分。这样做既保证公平，也避免学生通过浏览器调试工具直接修改页面上的分数。

3.4 成绩中心：多维度成绩与权重汇总的公式落地

总评成绩的计算是这个系统容易出错的地方。我按照医学电子技术课程的实际评分规则，把成绩划分为五个维度：

业务上需要允许不同课程配置不同权重，所以设计了一张权重配置表：

CREATE TABLE score_weight ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, attendance_weight DECIMAL(4,2) DEFAULT 10.00, quiz_weight DECIMAL(4,2) DEFAULT 20.00, report_weight DECIMAL(4,2) DEFAULT 30.00, homework_weight DECIMAL(4,2) DEFAULT 10.00, final_weight DECIMAL(4,2) DEFAULT 30.00 );

总评计算的实现思路是先在成绩汇总层做一次全量计算并缓存结果，前端打开成绩单时直接读取汇总数据，而不是每次请求都实时查五张表算平均分。这里我用了一个score_summary表做聚合，定时任务在每天凌晨重新计算一次。考量是学生成绩的查询频率远高于修改频率，缓存结果能显著降低数据库压力，也避免老师在浏览成绩时系统卡顿。

4. 医学场景特有的几个“隐藏坑”与对应的处理方案

4.1 实验报告附件：“波形图 + 电路图 + PDF 作业”的文件类型与大小边界

医学电子技术实验报告的特殊性在于附件组成复杂。一份完整的报告通常包含：

• 手写或电子版的分析文字（Word/PDF）；
• 示波器波形截图（PNG/JPG）；
• 电路图或 PCB 截图（PNG）；
• 数据表格（Excel/PDF）。

很多学生图省事，把所有文件塞进一个 zip 压缩包提交。如果不做限制，上传功能就成了文件投毒通道。

我的处理方案是“白名单 + 双重校验”：

private static final List<String> ALLOWED_TYPES = Arrays.asList( "pdf", "doc", "docx", "xls", "xlsx", "png", "jpg", "jpeg", "gif", "zip", "rar" ); public void checkFile(MultipartFile file) { String originalName = file.getOriginalFilename(); String ext = originalName.substring(originalName.lastIndexOf(".") + 1).toLowerCase(); if (!ALLOWED_TYPES.contains(ext)) { throw new BusinessException("不支持的文件类型：" + ext); } if (file.getSize() > 50 * 1024 * 1024) { throw new BusinessException("文件大小不能超过 50MB"); } // 校验真实文件头，而不是只看扩展名 byte[] header = new byte[4]; file.getInputStream().read(header); // 简单判断常见图片/pdf 魔数，压缩包做二次嗅探 }

第二个坑是文件名里的中文和空格。学生从 Windows 上传“实验三 心电信号采集报告（新）.docx”这种文件，直接用原名存储很容易在下载时 URL 编码出错。统一解决方案：上传时用UUID + 扩展名重命名存储，数据库单独记录原始文件名。前端下载时把原始文件名放回Content-Disposition响应头里，浏览器就能正常理解。

还有一个细节是 zip 压缩包内的文件类型检查。只查压缩包后缀还不够，zip 里可能藏着可执行文件。需要解压扫描内部文件扩展名，发现危险类型直接拒绝上传。这个逻辑虽然多写几十行代码，但在高校环境里很有必要。

4.2 测验时长的公平性：服务端计时 vs 客户端计时

这个坑我在 3.3 节已经提到了核心设计，这里说为什么很多人会踩进去。

最初版本的前端倒计时是setInterval写在页面组件里的，毫秒数存在内存中。测试的时候发现，刷新页面倒计时重新开始，Chrome 的 “重新加载” 按钮按一下就能多获得一次完整考试时间。对机房里的学生来说，这就是一个公开的作弊漏洞。

改成服务端计时之后，又遇到一个体验问题：交卷瞬间如果网络慢，学生看到的是“正在提交”转圈，其实后端正在逐题比对答案并计算分数。这些计算本身不复杂，但上百个学生同时交卷时接口响应会明显变慢。后来加了 Redis 缓存学生答题记录，交卷前先批量写入答案，再做一次异步判分，交卷接口的响应时间从 3 秒降到了 500 毫秒以内。

如果你自己也做在线考试系统，记住一点：计时、判分、改分都必须相信服务端，前端所有的倒计时和得分只能作为展示。

4.3 成绩权重计算里的小数误差与精度问题

Java 世界里double做金额和成绩计算是大忌。一开始我用double算总评，出现了 89.99999999998 这种结果。前端展示倒还能四舍五入，但导出 Excel 排序时就会莫名其妙多出几位小数。

正确做法是成绩计算统一使用BigDecimal，数据库存取用DECIMAL。

BigDecimal attendanceScore = new BigDecimal("100").multiply( BigDecimal.valueOf(attendCount)) .divide(BigDecimal.valueOf(totalCount), 2, RoundingMode.HALF_UP); BigDecimal total = attendanceScore.multiply(attendanceWeight) .add(quizScore.multiply(quizWeight)) .add(reportScore.multiply(reportWeight)) .add(homeworkScore.multiply(homeworkWeight)) .add(finalScore.multiply(finalWeight)) .setScale(2, RoundingMode.HALF_UP);

这里的RoundingMode.HALF_UP表示四舍五入。成绩保留两位小数足够，不要用默认的四舍五入策略，Java 默认的RoundingMode.HALF_EVEN（银行家舍入）在某些分数边界上会“舍”掉学生应得的 0.005。实测中遇到过 79.995 被舍成 79.99 而不是 80.00 的情况，学生看到会非常难受。

4.4 生僻医学术语与特殊字符：富文本编辑器与字符集风险

医学电子技术的内容里充满μV、Ω、fC、ST 段抬高、QRS 波群这类特殊符号和上下标。普通input框根本存不了，必须用富文本编辑器。

富文本编辑器选型我比较保守，用了轻量的 wangEditor，核心原因是部署简单、对技术栈零侵入。但富文本有个老生常谈的问题——XSS 注入。学生如果在测验答题描述里塞一段 JavaScript，前端v-html渲染时就会执行。

我的做法是后端统一做 HTML 标签白名单过滤，只保留p、span、img、table、tr、td几个安全标签，其余全部取掉。同时数据库的表和连接统一使用utf8mb4字符集：

CREATE DATABASE med_edu DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

如果你用 MySQL 8.0，更推荐utf8mb4_0900_ai_ci排序规则。另外注意数据库连接 URL 必须带characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai，否则特殊字符入库时会乱码——这个问题部署环节还会再踩一次。

5. 数据库设计的三次返工：那些后来才想明白的表结构

这一节不讲最终方案，而是讲讲我踩过的三次大坑。数据库设计很多教训是“用的时候才发现的”，提前说出来能帮你少走弯路。

5.1 第一次返工：角色设计从“字段冗余”换成“三表关联”

最初的用户表设计得非常简单：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50), password VARCHAR(100), role TINYINT COMMENT '1-学生 2-教师 3-管理员' );

一个role字段搞定所有用户身份，看起来简洁。然而实际用起来第一个月就出了问题：有一个学生是老师的课程助教，需要同时以学生身份上课、以助教身份批改实验报告。单字段设计根本表达不了“既是学生又是助教”这种双重身份。

第二次设计改成了三表关联：

CREATE TABLE sys_role ( id BIGINT PRIMARY KEY, role_name VARCHAR(50) ); CREATE TABLE sys_user_role ( user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, PRIMARY KEY (user_id, role_id) );

sys_user里只保留基础账号信息，角色关系单独维护。用户模块的查询从一次select * from sys_user where role = 1变成了两次 join，但换来了极大的灵活性。任何人都可以拥有多个角色，权限判断也能做到按角色去路由菜单。

5.2 第二次返工：课程与班级的“多对多”困局

课程和班级的关系比我想象的复杂。一个老师教的一门课，往往有两个平行班在上。如果课程表里直接存class_id，一门课就只能在系统里建两条记录，但这两条记录其实是同一门课的同一个教学大纲、同一套课件、同一批实验项目。

正确的建模是加一张关联表：

CREATE TABLE course_class ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, class_id BIGINT NOT NULL, teacher_id BIGINT NOT NULL, semester VARCHAR(20) );

课程信息存一次，课程和班级多对多关联。选课功能本质上是往course_class和student_course（学生选课表）里插记录。这里如果没有跳出来重新建模，后面签到、成绩、实验报告的全链路都会跟着错。

5.3 第三次返工：成绩表要不要冗余总分

最早版本的成绩表只存各维度明细分，总评是查询时实时算的：

SELECT student_id, AVG(report_score) AS report_avg, AVG(quiz_score) AS quiz_avg, ... FROM score_detail GROUP BY student_id

学期末成绩全量导出时，这个查询要跑几十个 join 和聚合，数据库 CPU 直接拉满。更要命的是，权重配置一旦调整，整个成绩单就变了，前端缓存全部失效。与其每次实时算，不如定期把计算结果落库。

最终方案是在score_summary表里冗余存储每位学生的总评和各维度得分，用一个每周自动执行的定时任务或者当某一维度成绩发生变化时触发增量更新。

CREATE TABLE score_summary ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, student_id BIGINT NOT NULL, attendance_score DECIMAL(5,2), quiz_score DECIMAL(5,2), report_score DECIMAL(5,2), homework_score DECIMAL(5,2), final_score DECIMAL(5,2), total_score DECIMAL(5,2), update_time DATETIME, UNIQUE KEY uk_course_student (course_id, student_id) );

冗余存储的代价是数据可能短暂不一致，但对教学成绩这种非金融级别数据来说，几分钟的延迟完全可以接受。换来的是查询性能提升几十倍。

5.4 索引与字符集：几个容易被忽略的细节

数据库设计里最容易出问题的不是表结构，而是索引和字符集。

• 签到表必须有(course_id, student_id, create_date)联合索引，否则“查询某节课出勤名单”会变成全表扫描。
• 答题记录表必须加(exam_id, student_id)联合索引，交卷判分时按考试维度批量查询答案。
• 时间字段统一用datetime，不要varchar存时间字符串。排序和区间查询的性能差别巨大。
• 逻辑删除字段deleted默认加在所有业务表上。学生退选、老师删除公告这类操作，物理删除会让历史数据丢失，逻辑删除配合 MyBatis-Plus 的@TableLogic注解，一行配置全局生效。

一个实测案例：未加索引时，某课程的成绩明细查询耗时 1.8 秒；加完(course_id, student_id)联合索引后，同样的查询耗时 8 毫秒。这不是夸张，索引对中小型系统的性能提升就是这么明显。

6. 从源码到本地跑通：环境准备、部署步骤与联调排查

最后一部分是实操。无论你是拿到别人交付的源码，还是想自己复现这套系统，下面这套流程都能平滑跑通。

6.1 环境清单与版本匹配

建议按以下环境准备，版本之间互相兼容性最好：

JDK 版本和 Spring Boot 版本有对应关系，Spring Boot 2.2 需要 JDK 8 及以上。如果拿到的源码是 Spring Boot 2.7，建议直接用 JDK 11，避免某些 JVM 参数在新版本下报错。

6.2 后端启动的完整步骤与应用配置文件详解

第一步，新建数据库并导入 SQL：

mysql -u root -p CREATE DATABASE med_edu DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE med_edu; SOURCE /path/to/med_edu.sql;

第二步，修改application.yml：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/med_edu?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 50MB max-request-size: 200MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 # 文件上传存储路径 file: upload-dir: /data/med_edu/upload

这里最值得注意的有三点：

• allowPublicKeyRetrieval=true参数，MySQL 8.0 默认不自动获取公钥，不加这个参数连接时大概率报错。
• serverTimezone=Asia/Shanghai，不加这个，时区不对会导致datetime字段读写相差 8 小时。
• 上传路径要提前创建好并确保有读写权限，否则传文件时系统虽然能启动但会上传失败。

第三步，IDEA 里导入 Maven 项目，等待依赖下载完毕后直接运行MedEduApplication.java。看到 Spring Boot 启动成功的日志，后端就起来了。

6.3 前端启动步骤与跨域联调的三种方案

前端操作三步：

cd med_edu_frontend npm install npm run serve

npm install如果下载慢，先设置国内镜像：npm config set registry https://registry.npmmirror.com。

前后端分离的项目必然要处理跨域问题。三种方案里我推荐第一种：

方案一：前端开发服务器代理（devServer.proxy）

在vue.config.js里配置：

module.exports = { devServer: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };

这样前端请求/api/xxx时，开发服务器自动转发到后端的8080端口。浏览器里永远只看着localhost:3000，不存在跨域问题。这个方案不污染后端代码，生产环境部署时用 Nginx 同样配置反向代理即可。

方案二：后端开启 CORS

Spring Boot 里加一个配置类：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:3000"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

方案二胜在简单，开发调试方便，但生产环境如果把addAllowedOrigin("*")放开会有安全隐患，不建议长期使用。

6.4 本地联调的高频报错与排查思路

联调阶段整理了高频报错，直接做成排查速查表：

其中“前端 404”是新手最容易懵的场景。本质是前端地址栏输入/api/xxx，但这个请求根本没有被代理转发到后端。排查顺序是：先用浏览器直接访问http://localhost:8080/api/xxx，如果能通说明后端没问题；再检查前端代理配置。

最后再分享一点我自己的做事习惯。这套系统交付后，我写了一份给老师的操作文档，同时给接手这个项目的同学留了一份代码导读——按照“登录 -> 选课 -> 上课签到 -> 提交实验报告 -> 老师批改 -> 成绩汇总”这条业务主链路去追踪代码，比从 controller 到 service 到 mapper 逐个文件硬啃要快得多。

做类似项目的读者，我的建议是拿到源码后先别急着加功能。第一步把项目跑起来，每个模块点一遍，记录“这个页面点了会发生什么”；第二步找到一条核心业务链路，跟着请求从前端视图到后端接口走一遍；第三步才是动手改。教学管理系统这种 CRUD 密集型项目，理解一通百通。如果你打算在此基础上改造成自己的毕设，把课程表换成本专业课程，把报告模板换成对应格式，工作量不会太大，但要注意把数据库注释和接口文档一并更新，这习惯能让你在答辩时少挨很多问。