班主任管理系统毕业设计：SpringBoot+Vue+MySQL实战与开题

接手过好几回“班主任管理系统”这类题目的活儿，时间点基本都集中在开题季那两个月。对方丢过来的信息往往就只有标题这十来个字，后面跟一句“源码+开题”，翻译成人话其实是两件事：一套能跑起来、能演示、能应付检查的代码，以及一份能直接交上去、答辩时经得起追问的开题材料。这两个东西看起来是一回事，实际上是两条线——代码写得好不代表开题写得清，开题写得漂亮也可能压根没跑通过一行代码。这篇就把我在这类项目上反复验证过的东西摊开讲：系统该管什么、不该管什么，技术栈为什么落在 SpringBoot + Vue + MySQL 这条线上，成绩统计和排名这类看着简单的功能为什么会翻车，源码交付时目录该怎么组织，开题报告里“研究背景”“国内外现状”“技术路线”这几段怎么写出人味儿而不是模板味儿。适合正在做这类毕设的同学，也适合带这类课题、想快速摸清全貌的指导方参考。

1. 项目定位与整体设计拆解

1.1 先把“班主任到底在管什么”列清楚

很多同学一上来就打开 IDE 建工程，建完发现不知道该建几张表，于是开始百度“班级管理系统 数据库设计”，抄一份表结构回来，字段名对不上，后面全部推倒重来。我一般建议先把班主任一周的活儿在纸上过一遍，这个动作花不了半小时，但能省下三天返工。

一个真实的班主任，日常碰到的台账大概有这些：早上到班点人数、记迟到早退、请假条登记与审批、月考期中期末成绩录入与排名、学生基本信息（学号、姓名、性别、联系方式、家庭住址、家长联系方式、是否住校、宿舍号）、班费收支记录、德育分或操行评定、期末评语、班级通知与活动报名、家长沟通记录。这些东西现在绝大多数是靠 Excel 加微信群攒起来的，痛点很集中：多份 Excel 分散在不同人手里，改一版不知道哪版是最新的；成绩算排名要手工拉公式，一列拉错全表崩；评语要一个个复制模板再改，改到第五十个已经不知道自己在写什么了。

把这些痛点收拢一下，系统的边界就出来了。它不该去抢教务系统的活儿——排课、选课、学籍异动、教师考评这些不属于班主任的个人事务范畴，真做进去，数据源你也拿不到，答辩时老师一问“你的课表数据从哪来”就卡住了。它应该聚焦在“一个班主任管理自己带的班”这个视角上，核心是三类数据：人（学生档案）、事（考勤、请假、通知）、数（成绩、班费、操行分）。这个定位一旦立住，后面的模块划分和表设计基本是自动推导出来的，不会再东一榔头西一棒子。

角色上我一般设三个：班主任（超级权限，管本班全部数据）、学生（看自己的成绩、考勤、通知，提交请假）、家长（可选，只看自己孩子的成绩与考勤）。第三角色如果时间紧可以砍掉，但数据库里最好预留角色字段，答辩被问到“家长怎么参与”时有话可说，不至于只能回答“没做”。

1.2 技术栈为什么落在 SpringBoot + Vue 这条线上

选型这件事，答辩时几乎必被问“你为什么用这个技术”。回答“流行”“网上教程多”是要扣分的，得说清楚取舍逻辑。我整理了一张常见的对比表，实际项目里我也是按这个思路定的：

选 SpringBoot 的核心理由不是“流行”，而是自动装配把配置成本压到最低：一个application.yml里写数据库连接，加个 starter 依赖，内嵌 Tomcat 直接main方法启动，不用装外置容器、不用配web.xml。对一个人独立完成、还要写文档的毕设来说，这种“少配置”的价值远大于性能。Vue 这边选它的理由是组件化和数据驱动：成绩表格、考勤日历这些反复出现的结构，抽成组件后能省掉大量重复的 DOM 操作代码，而且v-model双向绑定让表单类页面写起来极快。

版本上我踩过的坑得提前说：SpringBoot 3.x 要求 JDK 17 起步，很多同学的机器上还是 JDK 8，硬上 3.x 会遇到一堆jakarta包名不匹配的问题（javax.servlet全变成jakarta.servlet，网上抄的代码全部编译不过）。所以稳妥起见，用SpringBoot 2.7.x + JDK 8 或 11这条线，资料最全，出问题最容易搜到答案。前端 Vue 2 + Element UI 或者 Vue 3 + Element Plus 都行，前者资料更多，后者更现代，看你熟悉哪个，别为了“新”去选一个自己调不通的。

1.3 模块切分与数据库骨架

模块划分我一般按“数据对象”切，而不是按“页面”切。按页面切会出现“学生列表页需要调三个接口”的混乱，按对象切则每个对象一套增删改查，接口复用率高。落到表上大概是这样一套骨架：

这里有两个设计取舍值得说。第一，成绩和考试批次分开。有的同学把exam_batch直接写成“月考一”“期中”这种中文字符串存在成绩表里，后期想按批次统计就得字符串匹配，非常难受。更好的做法是单独一张exam表存批次信息，成绩表只存exam_id外键指向，这样批次改名、加批次都不影响历史数据。第二，考勤和请假不要合并。请假是“申请-审批”流程，有状态流转；考勤是“某天某人的实际状态”记录。合并成一张表会出现“请假被驳回后考勤记录怎么处理”这种纠缠不清的问题。分开存，然后在统计时做关联，逻辑清爽得多。

还有个小细节：所有表我都加create_time、update_time、deleted三个字段。deleted配合 MyBatis-Plus 的逻辑删除，学生信息删错了还能捞回来，答辩时演示“误删恢复”是个很讨巧的加分项，实现成本却只有一行配置。

2. 核心功能的实现细节与坑点

2.1 学生档案与花名册：看起来最简单，最容易返工

学生档案是所有模块的地基，这张表一旦设计歪了，后面成绩、考勤、评语全要跟着改。我见过最常见的三个错误，都是动手太快导致的。

第一个错误是学号当成主键。学号确实唯一，但它会变——转专业、复学、插班都可能改学号，一旦拿它当主键并且做了外键关联，改一个学号要级联更新七八张表。正确做法是自增id做物理主键，student_no建唯一索引做业务主键。这个区分在答辩时说出来，是很能体现设计意识的。

第二个错误是把班级名直接存成字符串。学生表里塞一个class_name字段，听着省事，等班级改名（比如“高一(3)班”改成“2024级3班”）就得批量更新，还容易漏。用class_id外键关联class_info，班级改名只改一处。

第三个错误是逻辑删除没做，物理删除直接DELETE。学生转走了删一行，结果成绩表里的历史成绩全成了孤儿数据，统计报表直接崩。用deleted字段做逻辑删除，查询时框架自动拼WHERE deleted = 0，历史数据完好。

花名册页面本身没什么技术难度，但体验上有个小技巧：列表默认按学号排序，并且支持按姓名拼音首字母快速定位。实现上不用真去算拼音，前端加一个 A-Z 的索引条，点“L”就跳到姓名首字母为 L 的第一条。这个功能在演示时非常直观，评委一看就知道你考虑过真实使用场景，而代码量不过是给每条数据算个首字母然后分组。

导入导出也值得做。真实场景里，班主任手里一定有一份现成的 Excel 花名册，让他一条条手输是不可能的。用 EasyExcel 或 Apache POI 做一个模板下载 + 批量导入，把“下载模板→填数据→上传→预览校验→确认导入”这条链路走通，答辩时演示一次批量导入 50 条学生，效果比任何 PPT 都强。

提示：批量导入一定要有“预览校验”这一步，先解析到内存里展示，标红提示哪几行学号重复、哪几行手机号格式不对，用户确认后再落库。直接解析完就插入，一旦文件有问题，脏数据清起来比重录还麻烦。

2.2 成绩录入与统计：精度、排名、并列

成绩模块是整个系统里最容易被低估的部分。表面看就是存个分数，实际上坑集中在三个地方：精度、排名并列、统计口径。

精度问题。分数千万别用float或double存。浮点数在计算机里是二进制近似，0.1 + 0.2不等于0.3这是常识，成绩场景下更麻烦的是求和之后出现89.99999999这种值，平均分算出来一堆小数尾巴，四舍五入还会因为银行家舍入规则出现“87.5 显示成 87”的情况。统一用DECIMAL(5,2)，最高 999.99 分，两位小数，MySQL 内部是精确十进制存储，求和求平均都不会飘。Java 侧对应BigDecimal，做除法时必须指定精度和舍入模式，我一般这样写：

// 计算平均分，保留两位小数，四舍五入 BigDecimal sum = scores.stream() .map(Score::getScore) .reduce(BigDecimal.ZERO, BigDecimal::add); BigDecimal avg = sum.divide(new BigDecimal(scores.size()), 2, RoundingMode.HALF_UP);

注意第二个参数2和第三个参数RoundingMode.HALF_UP都不能省。BigDecimal做除法如果不指定精度，遇到除不尽的情况（比如 10 除以 3）会直接抛ArithmeticException，这个异常在测试数据量小的时候碰不到，一上真实数据就炸。

排名并列。这是最经典的一道坎。假设三个人分数是 95、95、90，正确排名应该是 1、1、3；如果用1、2、3就是错的。MySQL 8 提供了窗口函数，直接解决：

SELECT student_id, score, DENSE_RANK() OVER ( PARTITION BY exam_id, course_id ORDER BY score DESC ) AS rank_in_class FROM score WHERE exam_id = #{examId} AND deleted = 0;

DENSE_RANK()是并列同名次、下一个名次不跳号（95、95、90 → 1、1、2）；RANK()是并列同名次、下一个名次跳号（1、1、3）；ROW_NUMBER()是强行不并列（1、2、3）。学校场景下用RANK()更符合“并列第一，下一名第三”的直觉，用DENSE_RANK()的学校也有，选哪个都行，但一定要在开题或论文里写清楚你用的是哪个、为什么，被问到能答上来就是加分。

如果数据库版本低于 8.0，窗口函数用不了，就得自己在 Java 里排序后遍历赋值，逻辑是维护一个“当前名次”和“上一个人分数”，分数相同名次不变。这段代码不长，但很容易写成rank = i + 1的低级错误，写完用 95、95、90、90、85 这组数据测一遍再交。

统计口径。班主任真正关心的不是平均分，而是及格率、优秀率、低分人数这几个指标。这几个指标的分母到底是“班级总人数”还是“实考人数”，差别很大。缺考的学生算不算进去？我一般让页面提供开关，默认用实考人数，同时在表头小字注明口径。指标公式写在下面，直接可用：

标准差这个指标很多同类系统没有，加进去成本极低（一行 Java 循环），但能体现你对统计的理解。分数标准差大说明班级两极分化，班主任看到这个数字就知道该重点关注哪批学生，这是真正的“有用”而不是“好看”。

2.3 考勤与请假：状态机比表结构更重要

考勤模块的复杂度不在字段，在状态之间的流转关系。学生提交请假申请，状态是“待审批”；班主任批准，变“已批准”；驳回，变“已驳回”；学生可以撤回，变“已撤销”。这四个状态之间的合法跳转就那么几条，其他的都是非法操作。我的做法是在 Service 层用枚举卡死跳转，而不是在 Controller 里靠 if 判断：

public enum LeaveStatus { PENDING("待审批"), APPROVED("已批准"), REJECTED("已驳回"), CANCELED("已撤销"); private final String label; LeaveStatus(String label) { this.label = label; } // 定义合法流转 public boolean canTransferTo(LeaveStatus target) { switch (this) { case PENDING: return target == APPROVED || target == REJECTED || target == CANCELED; default: return false; // 终态不允许再流转 } } }

这样写的好处是，所有状态规则集中在一处，答辩时被问“已批准的请假还能改吗”，直接指这段代码就行，不用翻遍 Controller。而且新加状态（比如“销假”）只改枚举和判断，不碰业务代码。

另一个容易忽略的点是请假批准后要自动写考勤。学生请假三天，这三天考勤状态应该自动标记为“请假”，而不是让班主任再去手动点三遍。实现上在审批通过的那一刻，遍历请假时间区间内的每一天，往attendance表插一条status = '请假'的记录，如果当天已有记录就更新。这里要注意唯一索引：(student_id, date)建唯一索引，插入时用ON DUPLICATE KEY UPDATE或者先查后插，否则同一天重复点审批会插出多条记录，统计数字直接翻倍。

考勤日历页面的展示我建议用月历视图，每一天格子里显示班级人数和学生状态色块，点开某天弹出当日明细。这个页面用 Element 的 Calendar 组件或者自己写个 7 列表格都行，关键是色块别用超过四种颜色，多了反而看不清。正常绿色、迟到黄色、缺勤红色、请假灰色，够了。

2.4 通知与评语：别把这些模块做成摆设

很多同类系统里，通知模块就是一个“发布-列表”的裸 CRUD，评语模块就是一个文本框，功能上确实能跑，但答辩时老师一眼就能看出这是凑数模块，问一句“这个通知和微信群有什么区别”就答不上来。

通知模块要做出差异，关键在已读状态和提醒。加一张notice_read表记录谁读了谁没读，班主任发布后能看到“已读 32/45”，点进去看未读名单，一键复制名单去催。这个功能实现成本很低（一张关联表 + 一个统计查询），但场景价值极高，因为“通知发出去没人看”正是微信群最大的痛点。这个对比在答辩时讲出来，说服力很强。

评语模块要有价值，得解决“写五十份评语写到词穷”的问题。我的做法是做一个分维度评语库：把评语拆成“学习态度”“纪律表现”“劳动卫生”“人际交往”四个维度，每个维度预置十条不同倾向的描述（正面、中性、待改进），班主任勾选组合，系统拼成一段完整评语，再手动微调。这样写一份评语从五分钟降到三十秒，而且是针对具体学生的，不是千人一面。评语库的初始数据可以直接写在 SQL 初始化脚本里，交付时一并给出，用的人一打开就有东西可用。

这里有个数据结构的小技巧：评语库别用一张表加type字段，用dimension+polarity两个字段组合，查询时按维度分组、按倾向排序，前端渲染成两列勾选框，交互非常顺。

2.5 权限控制：三个角色的边界

权限这块，很多同学的做法是“前端把菜单藏起来”，后端接口完全不设防，用 Postman 直接调接口什么都能改。这个漏洞答辩时不一定被发现，但它反映的是设计意识问题，而且改动成本其实很低。

我一般用 JWT + 拦截器这套轻量方案，不上 Spring Security，因为后者的配置复杂度对毕设来说是过度设计。核心链路是这样的：登录接口校验账号密码（密码用 BCrypt 存哈希，不存明文），通过后签发一个 Token，把userId、role、classId塞进 payload；前端每次请求在 Header 里带Authorization: Bearer xxx；后端一个拦截器统一解析 Token，把用户信息放进ThreadLocal，Controller 里随时取。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception { String token = req.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { resp.setStatus(401); return false; } try { Claims claims = JwtUtil.parse(token.substring(7)); UserContext.set(new LoginUser( Long.valueOf(claims.get("userId").toString()), claims.get("role").toString(), Long.valueOf(claims.get("classId").toString()) )); return true; } catch (Exception e) { resp.setStatus(401); return false; } } @Override public void afterCompletion(HttpServletRequest req, HttpServletResponse resp, Object handler, Exception ex) { UserContext.clear(); // 必须清，线程池复用会串数据 } }

afterCompletion里的clear()是最容易漏的一行。Tomcat 的线程是复用的，不清 ThreadLocal，下一个请求可能读到上一个用户的身份，出现“A 登录着看到 B 的数据”这种灵异现象，而且极难复现。我在这上面栽过一次，排查了大半天。

至于数据行级权限，也就是“班主任只能看自己班的学生”，靠的是在 Service 层拼条件：所有查询自动带上class_id = 当前用户.classId。这个用 MyBatis-Plus 的QueryWrapper加一行就行，但一定要在所有列表查询里都加，漏一个就是越权。

3. 从空目录到跑起来的实操过程

3.1 环境清单与版本对齐

版本不对齐是最常见的“跑不起来”原因，先把清单钉死：

Maven 的settings.xml里加一段镜像，能省掉大量等待：

<mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror>

数据库连接串有几个参数必须带上，少一个就出问题：

spring: datasource: url: jdbc:mysql://localhost:3306/class_manager?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

characterEncoding=utf8管中文乱码，serverTimezone=Asia/Shanghai管时间差八小时（不加这个，存进去的create_time会莫名其妙少八小时），allowPublicKeyRetrieval=true管 MySQL 8 默认加密方式导致的连接被拒。这三个参数我每次建项目都要默写一遍，因为每个都是踩过坑才记住的。

3.2 建表脚本与关键字段说明

建表脚本我建议直接放在src/main/resources/sql/init.sql，随源码交付，同时把初始化数据（测试班级、50 条学生、几组成绩、评语库）一并写进去。这样别人拿到源码，执行一遍脚本就能跑，不用问“数据从哪来”。核心几张表的关键片段：

CREATE TABLE `student` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `student_no` VARCHAR(20) NOT NULL COMMENT '学号，业务唯一', `name` VARCHAR(50) NOT NULL COMMENT '姓名', `gender` TINYINT DEFAULT 0 COMMENT '0未知 1男 2女', `class_id` BIGINT NOT NULL COMMENT '所属班级', `phone` VARCHAR(20) DEFAULT NULL, `parent_phone` VARCHAR(20) DEFAULT NULL, `is_boarder` TINYINT DEFAULT 0 COMMENT '是否住校', `deleted` TINYINT DEFAULT 0 COMMENT '逻辑删除', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_no` (`student_no`), KEY `idx_class_id` (`class_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生档案'; CREATE TABLE `score` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `student_id` BIGINT NOT NULL, `course_id` BIGINT NOT NULL, `exam_id` BIGINT NOT NULL COMMENT '考试批次', `score` DECIMAL(5,2) NOT NULL COMMENT '得分，两位小数', `rank_in_class` INT DEFAULT NULL COMMENT '班内排名，统计后回写', `deleted` TINYINT DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `uk_stu_course_exam` (`student_id`, `course_id`, `exam_id`), KEY `idx_exam_course` (`exam_id`, `course_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩';

注意score表上的唯一索引(student_id, course_id, exam_id)，这个索引能从根本上杜绝“同一场考试同一科目同一个学生录了两次”的脏数据。成绩录入页面即使连点两次提交，第二次也会被数据库拦下来，报一个唯一键冲突，前端提示“该学生该科目成绩已存在，请修改而非新增”。这比在 Java 里先查后插可靠得多，因为后者存在并发窗口。

3.3 后端接口的落地写法

后端按 Controller-Service-Mapper 三层写，Controller 只做参数接收和结果封装，业务逻辑全在 Service。返回体统一封一个Result：

@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMsg("success"); r.setData(data); return r; } public static <T> Result<T> fail(String msg) { Result<T> r = new Result<>(); r.setCode(500); r.setMsg(msg); return r; } }

统一返回体最大的价值不是好看，是前端能写一个统一的响应拦截器：code === 200就取data，否则弹错误提示并 reject。这样每个页面都不用重复写if (res.code === 200)。

分页这块，MyBatis-Plus 需要显式注册分页插件，不注册的话Page对象传进去不生效，返回的还是全量数据。这个坑几乎人人都踩：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

成绩统计的 Service 方法我贴一个完整的，包含平均分、及格率、优秀率、标准差的算法：

public ExamStatVO statByExam(Long examId, Long courseId, Long classId) { List<Score> list = scoreMapper.selectByExam(examId, courseId, classId); if (list.isEmpty()) { return ExamStatVO.empty(); } Course course = courseMapper.selectById(courseId); BigDecimal full = BigDecimal.valueOf(course.getFullScore()); BigDecimal passLine = full.multiply(new BigDecimal("0.6")); BigDecimal excellentLine = full.multiply(new BigDecimal("0.85")); int passCount = 0, excellentCount = 0; BigDecimal sum = BigDecimal.ZERO; for (Score s : list) { sum = sum.add(s.getScore()); if (s.getScore().compareTo(passLine) >= 0) passCount++; if (s.getScore().compareTo(excellentLine) >= 0) excellentCount++; } int n = list.size(); BigDecimal avg = sum.divide(BigDecimal.valueOf(n), 2, RoundingMode.HALF_UP); // 标准差 BigDecimal sqSum = BigDecimal.ZERO; for (Score s : list) { BigDecimal diff = s.getScore().subtract(avg); sqSum = sqSum.add(diff.multiply(diff)); } BigDecimal variance = sqSum.divide(BigDecimal.valueOf(n), 6, RoundingMode.HALF_UP); double stdDev = Math.sqrt(variance.doubleValue()); ExamStatVO vo = new ExamStatVO(); vo.setAvgScore(avg); vo.setPassRate(BigDecimal.valueOf(passCount * 100L).divide(BigDecimal.valueOf(n), 2, RoundingMode.HALF_UP)); vo.setExcellentRate(BigDecimal.valueOf(excellentCount * 100L).divide(BigDecimal.valueOf(n), 2, RoundingMode.HALF_UP)); vo.setStdDev(BigDecimal.valueOf(stdDev).setScale(2, RoundingMode.HALF_UP)); vo.setTotalCount(n); return vo; }

这里有个细节值得说：compareTo而不是equals。BigDecimal的equals会比较 scale（小数位数），new BigDecimal("60.0").equals(new BigDecimal("60"))返回false，而compareTo返回 0。这个坑在及格率统计里会造成“明明 60 分却不算及格”的诡异现象，非常隐蔽。

3.4 前端页面骨架与请求封装

前端用axios做统一封装，核心是请求拦截器加 Token、响应拦截器统一处理错误：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) request.interceptors.response.use( res => { const data = res.data if (data.code === 200) return data.data Message.error(data.msg || '请求失败') return Promise.reject(new Error(data.msg)) }, err => { if (err.response && err.response.status === 401) { localStorage.removeItem('token') router.push('/login') Message.warning('登录已失效，请重新登录') } else { Message.error('网络异常，请稍后再试') } return Promise.reject(err) } ) export default request

路由守卫负责挡未登录访问：

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

按角色的菜单控制，我的做法是在路由meta里写roles: ['teacher']，守卫里比对当前用户角色，不匹配就跳 403 页面。这个比在后端动态返回菜单简单得多，毕设场景够用。

页面本身，成绩录入我强烈建议做成表格内联编辑，一行一个学生，双击分数单元格直接改，改完失焦自动保存。这比“点编辑→弹窗→填→确定”的流程快十倍，而且演示效果非常好。Element 的el-table配合@cell-dblclick就能实现，代码不超过三十行。

3.5 打包部署与演示环境

交付和演示是两个环境，别混。演示环境就是你答辩那台笔记本，必须做到断网也能跑，因为答辩教室的网络谁也说不准。所以前端别依赖任何 CDN，npm run build之后把静态资源本地化；后端依赖全部打进 jar，java -jar直接起。

打包命令：

# 后端 mvn clean package -DskipTests nohup java -jar class-manager.jar --spring.profiles.active=prod > app.log 2>&1 & # 前端 npm run build

前端dist目录丢给 Nginx，关键是 history 模式下的try_files配置，不加的话刷新页面直接 404：

server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; } }

如果不想装 Nginx（答辩临时装环境风险太大），直接把dist里的文件丢进 SpringBoot 的src/main/resources/static，重新打包成一个大 jar，一个java -jar搞定前后端。这个方案不优雅，但演示场景下最稳，我从来都是给学生推这个方案，因为它把变量降到最少。

4. 开题报告怎么写才不像模板

4.1 研究背景与意义：从台账痛点切入

“研究背景”这一段，十个同学里八个写成了宏大叙事，从信息化时代讲到教育现代化，通篇没有一个具体场景。这种写法老师扫一眼就知道是从网上攒的。有效的写法是从一个具体的工作场景切入，把痛点亮出来，让读者产生“这确实是个事”的共鸣。

我一般这样组织：先是场景描述——一位带 45 人的班主任，每学期要手工处理约 800 条成绩记录、120 条考勤记录、45 份评语，这些数据分散在若干份表格里，更新时容易产生多个版本，统计排名靠手工拉公式，出错后需要全表复核；然后是问题归纳——数据分散、口径不一、重复劳动、历史数据难以追溯；最后落到“因此需要一个面向单个班级、聚焦班主任日常事务的轻量工具，把分散的表格收敛成结构化数据，把重复的手工计算交给系统”。这个逻辑链条是自洽的，而且完全是技术视角，不涉及任何宏观叙事。

“研究意义”别写成“具有重要意义”这种空话，拆成两层写：实用层面，把统计计算、排名、评语组合这些重复劳动自动化，把数据收敛到单一来源，降低出错率；技术层面，作为一次完整的工程实践，覆盖需求分析、数据库设计、接口开发、前端交互、部署运维的全流程。务实、可验证，比任何宏大表述都管用。

4.2 现状综述与技术路线

现状部分最容易写成“某某系统功能强大但价格昂贵”这种没有信息量的话。我的建议是按功能维度分横向对比，而不是按产品罗列。可以分成三类：综合性的校园管理平台、通用的表格协作工具、面向个人的轻量工具。然后指出各自在“单个班主任的日常事务”这个具体切口上的适配情况——平台类功能全但配置重、上手成本高；通用表格灵活但无结构约束、无权限边界；轻量工具贴近场景但功能零散。这样一对比，你要做的东西定位就清楚了：在通用表格的灵活和平台的重之间，取一个聚焦班级事务的中间态。

技术路线这一段，要写清楚“用什么、为什么用、怎么用”。我在上面 1.2 已经给了选型对比表，开题里可以直接把结论落成文字，每个选型后面跟一句理由：SpringBoot 是因为自动装配降低配置成本、生态成熟便于排错；Vue 是因为组件化复用了表格与表单结构；MySQL 是因为事务与窗口函数支持排名统计；MyBatis-Plus 是因为单表 CRUD 能省掉大量模板代码。每一条理由都要能对应到具体的功能点上，不能是泛泛的“性能好”“易扩展”。

技术路线最好配一张分层的文字说明，写清楚表示层、业务层、数据层各负责什么，接口如何交互。这不违反“不用图表”的要求，用文字分点写就行。

4.3 进度安排与工作量证明

进度表不能只是几个时间段的罗列，要能体现工作量分布。我一般按周拆，每周末尾写清楚“产出物”是什么，这样老师一眼能看出你每周在干什么：

有了“产出物”这一列，“工作量”就有了可验证的落点，不至于被问“你这两周到底做了什么”时答不上来。另外建议在表后面补一段说明风险与应对：比如数据库版本不兼容窗口函数怎么办（降级为 Java 内存排序）、前端构建环境不一致怎么办（锁定 Node 版本并写进 README）。主动写风险，比被动被问强。

4.4 答辩前必须自问的六个问题

开题和答辩是同一套逻辑的两端，写开题的时候就该想到答辩会被问什么。我整理了六个高频问题，每个都得有准备好的答案：

把这六个问题的答案写进开题的“关键问题与解决思路”一节，既是给自己梳理，也是给评阅人一个明确的技术信号。

5. 常见问题排查实录

5.1 环境与配置类问题

这类问题占了新手卡壳时间的七成，而且多数有固定解法。我按出现频率排了一张速查表：

跨域这块多讲一句，因为在 SpringBoot 2.7 上有个变化：allowedOrigins("*")在带凭证的请求下会失效，得用allowedOriginPatterns("*")。而且如果你的拦截器是自己写的，一定要在preHandle里判断if ("OPTIONS".equals(request.getMethod())) return true;，否则浏览器的预检请求直接被 401 挡掉，前端看到的报错信息会非常迷惑，提示跨域但实际是鉴权拦截。

5.2 数据与业务逻辑类问题

业务逻辑的 bug 往往比环境问题更隐蔽，因为系统能跑，只是结果不对。这几个是我反复见到的：

排名并列算错。前面讲过，用RANK()还是DENSE_RANK()要统一，别在统计页面用一套、导出 Excel 用另一套。更隐蔽的是缺考学生算进排名，考了 0 分和缺考是两回事，缺考应该在排名里排除，或者在成绩字段上允许NULL表示缺考，统计时过滤掉。

逻辑删除和唯一索引打架。student表建了student_no唯一索引，学生被逻辑删除（deleted = 1）后，再录入同一个学号会报唯一键冲突。解决办法是把唯一索引改成(student_no, deleted)联合唯一，或者用删除时间戳代替 0/1。这个问题在答辩演示时如果被撞上，场面会很尴尬。

事务边界没把控好。成绩批量导入时，逐条插入且不开事务，中途某条数据格式不对抛异常，前面已经插进去的几十条就成了半截数据。正确做法是在 Service 方法上加@Transactional(rollbackFor = Exception.class)，注意rollbackFor必须写，因为默认只回滚RuntimeException，受检异常不回滚——这个默认行为坑过无数人。

统计口径前后不一致。列表页显示“班级平均分 82.5”，点进详情页算出来 83.1，原因是列表页用的是分页查询后的当前页数据算的。所有统计必须走独立的聚合查询，从全量数据算，别拿页面上的列表数据二次加工。

5.3 上线演示类问题

演示环节的翻车往往和技术无关，纯粹是准备不足。我列几条实打实的心得。

演示数据一定要提前造好，而且要造得“像真的”：姓名用常见姓名，成绩分布要合理（别全在 90 分以上，也别全是 40 分），至少有一个并列名次的场景，至少有一个请假待审批的记录，至少有一条未读通知。这些细节能让演示过程中每个功能都有东西可点，不会出现“点进去是空列表”的尴尬。造数据的 SQL 单独存一个demo_data.sql，演示前执行一遍就有。

准备两套启动方式。一套是完整的 Nginx + 后端 jar，一套是前端塞进 static 的单 jar。如果现场环境出问题，直接切单 jar，一条命令起服务，风险最小。

别在现场装环境。数据库、JDK、Node 这些东西提前在自己机器上跑通，演示就用这台机器。现场下载安装包、等依赖下载，十分钟就没了，评委的耐心也一起没了。

留一个离线兜底。如果真出问题起不来，至少要有录屏。不是偷懒，是给自己留条退路。录屏要按演示脚本走一遍，把每个功能点都覆盖到，时长控制在五分钟以内。

导出功能一定要测。Excel 导出看着简单，实际上是演示时最容易出问题的功能，因为涉及文件流、浏览器下载行为、中文文件名编码。中文文件名要设URLEncoder.encode(fileName, "UTF-8")，响应头Content-Disposition里用filename*=UTF-8''的格式，不然下载下来的文件名是乱码。这个细节我改过三次才稳定。

我个人在这些项目上最有体会的一点是：把功能砍到能做扎实的程度，比堆一堆半成品强得多。一个只有学生档案、成绩统计、考勤请假、通知四个模块，但每个模块都能顺畅跑通、数据准确、异常有提示的系统，评分一定高于一个列了十二个模块、其中八个点进去报错的系统。开题里列功能清单的时候就要克制，写上去的每一条都要能兑现，兑现不了的就从清单里划掉，别留给自己挖坑。

另外一个小心得是关于源码交付的目录组织。我在根目录放一个README.md，写清楚环境要求、建库执行哪个脚本、怎么启动后端、怎么启动前端、默认账号密码是什么、演示数据怎么导入。这五件事写清楚，别人拿到手十分钟能跑起来。很多同学交付的压缩包里就一个工程文件，连数据库脚本都没放，收的人打开一脸茫然，这在评审环节是很掉分的。README 花二十分钟写，能省掉后面一堆解释成本，这个投入产出比在任何项目里都是最高的。