SpringBoot+Vue+MySQL实现毕业设计成绩管理系统：从数据库设计到部署全流程

如果你正在为毕业设计选题发愁，或者已经定了“成绩管理系统”这个方向但不知道从哪下手，这篇内容应该能帮你省下不少折腾时间。SpringBoot + Vue + MySQL 这套组合做毕业生成绩管理系统，算是经典中的经典，经典意味着资料多、坑也都被踩烂了，反而更适合用来冲一个稳妥的高分毕设。市面上大多数成绩管理系统演示的都是最简单的“查分”功能，但真正的毕业设计场景里，学生要上传论文、教师要多维度评分、管理员要分配答辩小组，还要能导出统计表——这里面每一层都有实打实的业务逻辑可写。

我会把这个项目的完整骨架拆给你看，从技术选型逻辑、数据库表设计，到后端鉴权、前端权限控制、最终部署上线的全套流程，都会讲到。文章里出现的思路和代码片段，都是我实际带过类似项目后总结出来的方案，不是教科书式的假大空，而是直接可以抄作业的版本。无论你是想自己动手写代码，还是已经拿到了一套源码想搞懂每一块在干什么，这篇内容都能帮你把体系理清。

1. 项目拆解与技术选型思路

1.1 为什么是 SpringBoot + Vue + MySQL，而不是别的组合

先说结论：这套组合是当前高校毕业生设计里最稳妥、性价比最高的选择。

很多人会纠结要不要用 SSM（Spring + SpringMVC + MyBatis）这种老框架，因为学校课程还在教。我的建议很直接：既然做毕设，就用 SpringBoot。SpringBoot 并不是什么“额外的新东西”，它本质上还是 Spring，只是把大量繁琐配置自动化了。你课程里学的 Spring 知识照样能用，但 SpringBoot 内置 Tomcat、支持 Starter 一键引入依赖、项目启动不用再去配置一堆 XML，这些好处能让你少掉很多头发。尤其是部署环节，老 SSM 项目要装外部 Tomcat、配置一大堆依赖版本，而 SpringBoot 直接打一个 jar 包就能跑，省掉的事情不是一点半点。

前端选 Vue 也同样基于这个逻辑。Vue 的组件化开发让复用变得非常舒服，比如评分表单、成绩图表、用户表格这些模块，封装一次就能到处用。配合 Element Plus 这种现成的后台组件库，页面做出来干净整齐，视觉上已经赢了一半。而且 Vue 的生态和学习曲线在三大框架里对新手最友好，中文资料多，出了问题基本都能搜到解决方案。

数据库方面，MySQL 在高校、企业在行业里的认知度都是最高的。虽然现在很多团队爱用 PostgreSQL，但对一个本科毕设来说，MySQL 依然是最不会出错的选择——网上教程多、服务器安装简单、面试官也认可。性能和功能上，MySQL 完全能撑起一个院系的毕业设计成绩管理系统。

1.2 这个管理系统到底要管什么

很多同学对“成绩管理系统”的理解停留在“录分数、查分数”，如果真这么做，项目工作量根本撑不起一篇像样的毕业论文。毕业设计成绩管理系统，管理的是从选题到答辩的完整流程。

我把这个项目拆成了七个模块，你可以对照着看自己手里的系统是否覆盖完整：

• 用户管理：管理员维护教师账号和学生账号，支持批量导入导出
• 课题管理：教师发布课题，学生在线选题
• 流程材料：学生上传开题报告、中期检查表、论文终稿
• 答辩分组：管理员创建答辩小组，分配学生到指定组
• 评分管理：答辩教师根据多维指标给每个学生打分
• 成绩汇总：系统按权重自动计算总分，生成等级和排名
• 数据可视化：学院领导或者管理员能看整体成绩分布统计

这里最关键的设计思路是：成绩不是一步算出来的，而是由不同阶段、多个教师、按不同权重组合出来的。正是因为成绩的“来源”足够复杂，系统才有深度可写，论文才有内容可讲。

1.3 角色权限的三层体系

权限设计是这类管理系统最核心的地方，也是答辩时最容易被抓着问的点。这个系统里存在三类角色，每类角色看到的东西完全不同：

• 管理员：能看到所有学生教师数据、配置评分指标和权重、管理答辩分组、查看全部成绩
• 教师：只能看到自己指导的学生，以及自己被分配到的答辩组学生，能录入评价分数，但不能修改其他教师的评分
• 学生：只能提交材料、查看自己的课题和最终成绩，看不到其他人的分数

天然的主从关系决定了权限要从接口层就做隔离，不能只靠前端隐藏按钮。后面第 3 部分我会详细讲后端怎么通过 JWT 和自定义注解实现权限控制。

2. 数据库设计与表结构规划

2.1 用户表的细节决定系统的上限

数据库是这个系统的地基，表设计得好，后面写代码会顺畅很多；表设计得烂，写着写着就会发现各种别扭。我建议用下面这套核心表结构，基本覆盖了大部分场景。

用户表是所有模块的枢纽，设计上有一个关键细节：学生和教师不要拆成两张表，而是用一张表加 role 字段区分。理由是两类用户很多字段是重合的（姓名、账号、邮箱），拆表会让关联查询变得繁琐；用一张表，配合 role 字段，既能用 MyBatis-Plus 做单表查询，又能在业务层区分角色逻辑。

CREATE TABLE `sys_user` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL COMMENT '登录账号', `password` VARCHAR(255) NOT NULL COMMENT 'BCrypt加密后的密码', `real_name` VARCHAR(50) NOT NULL COMMENT '真实姓名', `role` TINYINT NOT NULL COMMENT '0管理员 1教师 2学生', `student_no` VARCHAR(20) DEFAULT NULL COMMENT '学号，学生角色必填', `teacher_no` VARCHAR(20) DEFAULT NULL COMMENT '工号，教师角色必填', `major` VARCHAR(50) DEFAULT NULL COMMENT '专业', `class_name` VARCHAR(50) DEFAULT NULL COMMENT '班级', `email` VARCHAR(100) DEFAULT NULL, `phone` VARCHAR(20) DEFAULT NULL, `create_time` DATETIME DEFAULT NULL, `update_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT ='用户表';

密码字段有两个容易踩的坑。第一，不要用 MD5，MD5 在现在这个时代等于明文，答辩时如果被问到密码安全性，用 BCrypt 加密会是一个很好的加分回答。第二，密码长度不要只留 32 位，BCrypt 加密后的字符串长度是 60 个字符，字段长度不够会在注册时直接报错。

2.2 评分表：为什么一定要把“谁给谁打分”拆开

这是整个数据库设计里最关键的一张表，我见过很多设计把四个评分维度做成四个字段放在学生表里，比如 opening_score、midterm_score、paper_score、defense_score。这种设计乍一看没问题，但答辩组如果有多个教师，一个人的成绩是多位教师打分的平均分，一张学生表根本存不下多组分数。

正确做法是拆分评分表，把每一次评分动作变成一条记录：

CREATE TABLE `score_record` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `student_id` BIGINT NOT NULL COMMENT '被评分学生', `teacher_id` BIGINT NOT NULL COMMENT '评分教师', `group_id` BIGINT NOT NULL COMMENT '答辩分组', `opening_score` DECIMAL(5, 2) DEFAULT NULL COMMENT '开题报告得分', `midterm_score` DECIMAL(5, 2) DEFAULT NULL COMMENT '中期检查得分', `paper_score` DECIMAL(5, 2) DEFAULT NULL COMMENT '论文质量得分', `defense_score` DECIMAL(5, 2) DEFAULT NULL COMMENT '答辩表现得分', `comment` VARCHAR(500) DEFAULT NULL COMMENT '教师评语', `submit_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_teacher` (`student_id`, `teacher_id`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT ='评分记录表';

唯一的联合索引 (student_id, teacher_id) 非常关键，它保证了同一个教师不能对同一个学生重复评分。这个约束用代码也能实现，但数据库层面的唯一索引才是最后一道防线，能挡住并发请求下的重复提交问题。

2.3 权重配置与最终成绩计算

最终成绩不应该是代码里硬编码的公式。我见过一些项目把权重直接写死在计算逻辑里，比如总成绩 = 开题 0.1 + 中期 0.2 + 论文 0.5 + 答辩 0.2。这样做的坏处是：一旦学院调整了评分政策，你需要改代码重新部署，非常被动。

正确的做法是把权重配置做成一张表：

CREATE TABLE `weight_config` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `item_name` VARCHAR(50) NOT NULL COMMENT '评分项：开题报告/中期检查/论文质量/答辩表现', `item_code` VARCHAR(30) NOT NULL COMMENT '程序里用到的标识，如opening', `weight` DECIMAL(5, 2) NOT NULL COMMENT '权重百分比，如10.00表示10%', PRIMARY KEY (`id`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT ='评分权重配置表';

计算最终成绩时，程序从配置表里读取权重，再结合评分记录计算。这样管理员修改权重后，历史成绩可能需要重新计算，但至少不需要改代码。给你一个具体的计算示例，假设某学生被两位教师评分：

再按权重（开题 10%、中期 20%、论文 50%、答辩 20%）计算：

89 × 0.1 + 88.5 × 0.2 + 78 × 0.5 + 87.5 × 0.2 = 8.9 + 17.7 + 39 + 17.5 = 83.1

最终成绩就是 83.1，等级为良好。这一套计算逻辑写进论文里，既清楚又有说服力。

数据库层面还需要注意两个约定：所有金额、分数、百分比这类需要精确计算的数据，统一用 DECIMAL 类型，禁止使用 FLOAT 或 DOUBLE，否则会出现 0.1 + 0.2 不等于 0.3 这种尴尬问题。字符集统一使用 utf8mb4，不要用 utf8，因为 utf8 存不了 emoji 表情，也存不了部分生僻字，学生姓名里一旦出现这种字符就报错。

3. 后端架构与核心实现

3.1 分层结构与项目目录

后端工程我用经典的 Controller-Service-Mapper 三层结构，这是最容易被理解和维护的组织方式。项目包名建议顺时针分解，别把代码全堆在同一个包下面。

com.example.graduation ├── config # CORS跨域、MyBatis-Plus配置、JWT拦截器注册 ├── controller # 接口层，接收参数并返回结果 ├── service # 业务逻辑层 │ └── impl # 服务实现类 ├── mapper # MyBatis-Plus的Mapper接口 ├── entity # 数据库实体类 ├── dto # 接收前端参数的封装对象 ├── vo # 返回给前端的结果对象 ├── common # 统一返回体、异常处理、常量 └── utils # JWT工具类等

统一返回体是前后端协作的基础。我习惯用这种结构：

{ "code": 200, "msg": "操作成功", "data": { } }

业务异常时 code 用 400、401、403、500 区分。前端拿到非 200 的 code 后统一弹错误提示，不用每个接口单独写异常逻辑。

3.2 JWT 登录鉴权和角色控制

后端权限控制我用 JWT + 拦截器 + 自定义注解的三层组合。用户登录成功后，后端把用户 ID 和角色信息生成一个 token 返回给前端，前端在后续请求的请求头里带上 Authorization: Bearer token。后端拦截器解析 token，获取当前请求者的身份。

自定义注解 @RequireRole 是我比较推荐的一种做法。技术人员一般认为这里存在三类身份：答辩教师、学生、管理员。实际开发中用注解加在 Controller 方法上，代码会变得非常清爽：

@RequireRole({"admin"}) @PostMapping("/api/users/import") public Result<Void> importUsers(@RequestParam MultipartFile file) { userService.importUsers(file); return Result.success(); } @RequireRole({"teacher", "admin"}) @PostMapping("/api/scores/submit") public Result<Void> submitScore(@RequestBody ScoreSubmitDTO dto) { scoreService.submitScore(dto); return Result.success(); }

拦截器里先解析 token 获取角色，再比对当前接口允许的角色列表。如果角色不匹配，直接返回 403。这里有一个容易踩的坑：如果前端用到跨域请求，浏览器会先发送一个 OPTIONS 预检请求，这个请求不带业务请求头，拦截器如果对 OPTIONS 也做 token 校验，就会导致所有跨域请求全部失败。解决办法是在拦截器里先判断请求方法，如果是 OPTIONS 就直接放行。

3.3 核心接口与关键业务逻辑

这个系统最主要的接口我列在下面，写论文时可以直接作为系统功能清单使用：

评分提交是最核心的一个接口，逻辑包含三步：先判断当前教师是否属于该答辩组，如果不在组内直接拒绝；再通过唯一索引保证同一教师不能重复评分；最后检查这个学生是否已经集齐了答辩组内全部教师的评分，如果集齐就触发最终成绩计算。最终成绩计算时从权重表读取权重，按平均分公式算出总成绩，写入成绩汇总表。

3.4 Excel 导入与导出

管理几十个学生的账号手动录入非常低效，实际项目里一定要支持 Excel 批量导入。导入模板的列可以设计成：账号、姓名、专业、班级、邮箱。学生账号如果为空，可以使用学号作为默认账号；密码统一设为初始密码 123456，首次登录后在页面引导强制修改。

Excel 处理我推荐用 EasyExcel 而不是 Apache POI 直接操作。EasyExcel 底层还是 POI，但 API 设计友好很多，对内存的消耗也小，处理几千条数据基本无感。导出成绩汇总表的时候，用 EasyExcel 的 @ExcelProperty 注解直接映射实体字段，写一个导出工具类把查询结果写回响应流就行了。

后端的设计遵循一个原则：接口只负责接收参数和返回结果，所有业务规则都放在 Service 层。答辩时如果有人问你“多个教师评分怎么保证一致性”，你可以直接回答：评分记录表的唯一索引 + 最终成绩计算的触发条件监控，这两层共同保证了数据一致性。

4. 前端页面与交互细节

4.1 项目工程化与路由设计

前端我建议用 Vue3 + Vite + Pinia + Element Plus + ECharts 这套组合。Vite 启动速度比 Webpack 快很多，开发体验舒服，而且 Vite 目前在 Vue 生态里已经是主流选择。

前端的目录结构这样拆分比较清晰：

src/ ├── api/ # axios实例和每个模块的接口函数 ├── router/ # 路由配置与权限控制 ├── stores/ # Pinia状态管理 ├── views/ # 页面组件 │ ├── login/ # 登录页面 │ ├── admin/ # 管理员模块 │ ├── teacher/ # 教师模块 │ └── student/ # 学生模块 ├── components/ # 通用组件 └── utils/ # 日期格式化等工具

路由设计上，普通的前端项目是写死路由表。但这个系统有三种角色，学生不该访问管理员页面，教师也没必要看到学生上传材料入口，所以这里我会采用动态路由方案：登录后根据 Pinia 里保存的角色信息，用户路由表调用 addRoute 动态添加当前角色能访问的路由。这样即使在地址栏手动输入其他角色的路径，也只会进入 404 或 403 页面。

4.2 axios 封装与登录态处理

axios 封装是一切请求的入口。请求拦截器里做两件事：从 localStorage 拿 token 并加到请求头；如果 token 不存在且当前不是登录接口，直接跳转到登录页。响应拦截器里，如果 code 是 401 说明 token 过期或无效，清空本地用户信息再退回登录页。

这里有一个非常实用的细节：token 存 localStorage 没问题，但用户信息不要只存 localStorage。刷新页面时，要先调用一个 GET /api/auth/info 接口，根据 token 换回用户信息，然后再渲染路由和菜单。否则刷新后用户信息丢失，角色判断全乱，路由守卫会把人踢回登录页。这是一个很经典的前端刷新白屏问题，我见过不少同学在这里卡了很久。

4.3 评分页面的交互设计

评分页面是最容易体现“设计感”的地方。如果每一次评分都要老师手动填四个数字框，体验会比较生硬。更贴近真实使用的方式是：评分页面打开时显示学生基本信息、论文摘要和以往环节的得分，教师先有一个整体印象，再给各个维度打分。

我的设计是提供一个“预填默认分”按钮，点击后把当前学生的各项初始分设为 80，教师再根据自己的判断上下微调。这个功能虽然简单，但实际使用体验提升非常明显，在演示和答辩时也可以作为设计亮点讲给评委听。

输入的校验也需要注意：四个评分维度必须都是 0-100 之间的数字，保留两位小数，评语最多 500 字。提交前做一次完整校验，如果某个维度没填，明确提示是哪一个维度没填，而不是笼统提示“请完整填写评分表”。

4.4 成绩可视化与展示

学生端查看成绩时，除了显示最终总分和等级，还可以展示一张雷达图：开题、中期、论文、答辩四个维度都画在一张图上，一眼就能看出自己在哪个环节比较弱。用 ECharts 实现这个并不复杂，数据就是当前学生各维度的平均分，直接塞给雷达图的 indicator 和 data 就行。

管理员端也可以增加成绩分布图：柱状图展示各分数段人数，饼图展示优秀、良好、中等、及格、不及格的比例。这些图表的作用不只是好看，还能让答辩时的演示环节更有看点，评委看着图表，感觉比看干巴巴的数据库表格强太多了。

前端还有一个容易忽略但很重要的细节：成绩导出按钮要放在管理员页面的明显位置，而且导出文件命名要带日期，比如“2024届毕业设计成绩汇总_20240630.xlsx”。这样实际使用中才不会出现领导收到一堆同名文件无法区分的尴尬。

5. 部署上线的完整流程

5.1 本地环境搭建与配置

拿到项目源码后的第一步不是急着运行，而是先确认环境版本是否匹配。我建议用这套组合：JDK 17、MySQL 8.0、前端 Node 18 以上。如果后端项目基于 Spring Boot 3.x，JDK 版本必须是 17 及以上；如果是 Spring Boot 2.x，JDK 8 也能跑。先看 pom.xml 里 parent 节点确定版本，再安装对应的环境，能少走很多弯路。

配置文件的数据库连接信息是老生常谈的重点：

spring: datasource: url: jdbc:mysql://localhost:3306/graduation_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 servlet: multipart: max-file-size: 50MB max-request-size: 50MB

数据库连接 URL 里的 serverTimezone=Asia/Shanghai 一定要加上，否则 MySQL 8.x 会报时区错误。multipart 配置默认只允许 1MB 文件上传，如果不改，论文终稿文件稍微大一点就直接报错。

本地启动流程是标准的：先执行项目附带的 SQL 脚本初始化数据库；再修改 application.yml 里的数据库账号密码；后端执行 mvn clean package -DskipTests 打成 jar 包后运行；前端安装依赖后先 npm run dev 跑起来联调接口。联调通过后再执行 npm run build 生成 dist 静态文件，准备进入部署阶段。

5.2 云服务器部署实操

云服务器配置选择 2核4G 就够了，这个系统并发量本来就不高，撑住一个学院的正常使用完全没问题。部署前在云服务器安全组开放 80、443 和 22 端口，这部分操作在云厂商的控制台完成。

前端 dist 目录用 Nginx 托管，后端 jar 包直接跑在 8080 端口，Nginx 再把所有 /api 开头的请求反向代理到后端服务。Nginx 配置文件里的两个关键点：

server { listen 80; server_name 你的域名; root /var/www/graduation/dist; 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 / { try_files $uri $uri/ /index.html; } }

try_files 那一行非常关键，它解决的是前端 history 路由模式刷新 404 的问题。如果没有这一行，你在前端页面里点开某个详情页后按 F5 刷新，Nginx 找不到对应的真实文件路径，就会返回 404。有了 try_files，Nginx 会把所有找不到文件的请求都交给 index.html，再由前端的 Vue Router 接管路由。

后端进程不建议直接 java -jar 扔在后台，因为 SSH 断开后进程可能被系统杀掉。更好用的方式是注册成 systemd 服务：

[Unit] Description=Graduation System After=network.target [Service] Type=simple User=root WorkingDirectory=/home/app ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /home/app/graduation-system.jar Restart=always SuccessExitStatus=143 [Install] WantedBy=multi-user.target

配置好后依次执行 systemctl daemon-reload、systemctl enable graduation、systemctl start graduation，服务就能开机自启并且崩溃自动重启，比在终端里 nohup 稳得多。

5.3 HTTPS 与后续维护

现在部署网站基本都要上 HTTPS，浏览器会把不带 HTTPS 的网站标记为不安全。申请 SSL 证书用在线免费证书即可，配置完成后在 Nginx 里增加 443 端口的监听，把 HTTP 请求通过 return 301 https://$host$request_uri; 跳转到 HTTPS。

部署完成后的维护工作主要靠日志。后端日志建议用 logback 按天滚动记录，保留最近 30 天。查询问题先看后端日志，再看 Nginx 的 error.log，基本能定位大部分问题。

6. 常见问题排查与避坑实录

6.1 前端页面能打开，但是接口全部 404

这个问题的根源通常出在 Nginx 的代理配置上。我见过最典型的情况是：后端接口路径是 /api/users，前端请求也是 /api/users，但 Nginx 配置里只把 /api 开头的请求转发到后端，代码却是 proxy_pass http://127.0.0.1:8080/; 注意这个结尾多了一个斜杠。加斜杠的效果等于把请求路径里的 /api 前缀剥掉，转发到后端时变成 /users，而后端根本没有这个路径，自然就 404 了。

排查方法是打开浏览器开发者工具，看 Network 面板里实际请求的地址和返回状态。如果路径多了一层或者少了一层，直接对照修改 Nginx 配置。

6.2 上传文件提示“文件大小超限”

这是最常踩的坑之一。默认的 multipart 限制是 1MB，论文终稿带图表动辄十几 MB，肯定超限。解决办法是在配置文件里加上之前提到的 max-file-size 和 max-request-size，都设置成 50MB。需要注意 Nginx 层也有上传大小限制，需要在 Nginx 配置里加上 client_max_body_size 50m; 两层都设置好才能彻底解决。

6.3 成绩小数点精度对不上

如果数据库表里分数字段用了 DOUBLE，计算平均分时大概率会出现 83.10000000000001 这种结果。解决办法是数据库字段全部使用 DECIMAL(5,2)，Java 后端使用 BigDecimal，前端展示时用 toFixed(2) 统一格式化。计算过程注意先把所有分数按 BigDecimal 处理，再求平均、再乘权重，最后设置 setScale(2, RoundingMode.HALF_UP) 保留两位小数。

我实际测试时发现一个细节：求平均值时如果加起来除以人数，DECIMAL 除法会产生一个无限小数，所以必须在除法时直接指定精度，BigDecimal.valueOf(sum).divide(BigDecimal.valueOf(count), 2, RoundingMode.HALF_UP)。

6.4 前端刷新后变成 404

这个问题在第 5 部分已经说过，根因是开启了前端 history 路由模式。两点解决方案：一是浏览器地址栏里看到的是没有 # 号的干净路径，这是 history 模式；二是 Nginx 配置里的 try_files 必须加上。如果你不想折腾 Nginx，把 Vue Router 改成 hash 模式也能从根源解决，代价是地址栏里会多一个 # 号。所以前端路由选择可以权衡一下。

6.5 跨域请求被拦截

跨域问题只出现在前后端分离联调阶段，也就是前端跑在 5173 端口、后端跑在 8080 端口的时候。解决办法有两种。第一种是在 Vue 的 vite.config.js 里配置 devServer proxy，把请求代理到后端，这种方法开发时最常用。第二种是在后端加 CORS 配置，允许指定来源跨域访问。实际开发中我建议优先用 proxy，上线后由 Nginx 做反向代理，天然同源，前端代码里不用写死后端地址，维护成本更低。

6.6 数据库连接失败的常见原因

数据库连不上时，先看三个地方：报错信息是不是 Access denied，如果是，说明账号密码错误或者数据库用户权限不够；是不是 Communications link failure，如果是，说明网络不通或者 MySQL 没有启动；是不是 Communications link failure 但本机能连，说明安全组没有放行 3306 端口。

还有一类隐蔽问题：云服务器和数据库不在同一个服务商内网时，MySQL 默认只绑定 127.0.0.1，外部访问不到。需要在 MySQL 配置文件里把 bind-address 改成 0.0.0.0，并给 root 账号授予远程访问权限。生产环境这么做有安全风险，建议单独创建一个应用专用账号，只授予当前数据库的增删改查权限，密码设置复杂一点。

7. 这套系统的扩展方向与答辩加分项

7.1 增加导师课题双向选择机制

固定分配选题是最简单的逻辑，但真实场景中往往是教师发布课题、学生申请、教师确认的双向选择过程。在现有表结构上增加一张 application 表，记录学生申请了哪些课题，课题状态从“申请中”变为“已确认”或“已拒绝”。这个过程涉及状态流转、截止时间判断、教师端审批操作，复杂度比固定分配高一个档次，写进论文里也能体现你对业务场景的理解。

关键实现细节：要防止学生同时申请多个课题最终被多个教师确认，造成一稿多投。解决思路是在确认动作发生时，事务内判断该学生是否已有状态为“已确认”的课题，有则不通过。这个并发控制是答辩时非常能打的加分点。

7.2 论文关键词查重雏形

知网查重不用想了，但可以做一个基础版：学生上传论文终稿时，后端提取摘要和正文前几段文字，用 IK 分词器切词后与历史课题库做相似度匹配。匹配度超过阈值就提示可能存在重复内容，由管理员人工审核。虽然精度和商业查重系统没法比，但增加这个功能后，项目就从“增删改查管理系统”提升到了“具备一定业务智能的系统”，含金量明显不同。

7.3 答辩安排消息通知

答辩组和答辩时间确定后，系统可以自动给相关学生发送站内信通知，也可以在用户中心显示待办事项，比如“距离答辩还有 3 天”“您的评分尚未提交”。这个扩展点不需要引入消息队列，一张通知表和一套定时任务就能搞定，但在论文里可以描述为“消息推送模块”，听起来完整度会高不少。

我见过不少同学死磕一个复杂的炫技功能，结果核心业务却漏洞百出。我的建议是扩展功能做一个、两个足够，优先保证核心流程的完整性和健壮性。准确把数据库关系理清楚、权限控制做到位、核心评分流程跑通且计算结果准确，这三件事做好了，已经能超过大多数毕业设计了。

最后说一点我的个人体会。毕业设计成绩管理系统这类选题，和电商、社交平台比起来确实不算炫酷，但正因为逻辑清晰、边界明确，才更适合完整走完一个软件项目的全流程。做完这个项目，你对 SpringBoot 的自动配置、JWT 鉴权、Vue 路由守卫、Nginx 反向代理、服务器部署这五件事的理解，会比你慕课网刷三门课都扎实。而这些能力，恰好是日常开发工作中最高频的那部分。如果这篇文章里哪块还有疑问，照着章节回去翻对应小节，绝大部分问题你都能在里面找到答案。