又到了一年毕业季，办公室里的导师们开始翻着Excel表格来回核对评阅成绩，答辩秘书则抱着打印版评分表一份份誊抄。一个学生的总成绩，要汇总指导老师评分、评阅老师评分、答辩小组评分三份数据，中间只要有一个数字录错，最后排名就会乱掉。我前后帮几个实验室搭过这种成绩管理的小系统，这次干脆把一套完整的毕业设计成绩管理系统从需求、数据库、后端到前端梳理了一遍。项目采用SpringBoot+Vue+MyBatis架构，搭配MySQL数据库，适合正在做毕设选题的学生、想快速搭建后台管理系统的开发者，以及需要给学院或实验室内部做一套成绩管理工具的人参考。这篇文章不吹架构不扯理论，直接讲这套系统是怎么从零跑起来的。
1. 先搞清楚业务再动手：毕业设计成绩管理的真实需求
很多人拿到"成绩管理系统"这类题目，第一反应就是做增删改查。但毕业设计成绩管理跟普通的学生选课成绩管理完全不是一回事，它的业务流程要复杂得多。你不能上来就建表，得先想清楚：到底有哪些角色在用这套系统，每个角色的权限边界在哪里，成绩是怎么流转的？
1.1 角色梳理：学生、指导教师、评阅教师、答辩组、管理员
一套毕业设计成绩管理系统涉及的参与者至少有五类：学生、指导教师、评阅教师、答辩评审、系统管理员。学生需要提交论文材料、查看自己的最终成绩；指导教师需要录入指导环节的评分和评语；评阅教师需要独立打分；答辩评审需要录入答辩表现分；管理员则负责初始化学生名单、分配指导教师、设定成绩权重比例、最终导出成绩单。
这五个角色听起来都是"登录进去填个分数"，但权限差异极大：学生绝不能看到其他同学的成绩，指导教师只能看到自己带的学生，评阅教师只能看分配给自己的论文。这个权限模型是整个系统最基本的结构骨架，后端在做登录认证和接口鉴权的时候，必须把这五类身份区分开。
1.2 成绩构成逻辑：一套分数是怎么算出来的
毕业设计总成绩通常不是单个分数，而是由多个环节加权汇总。我参考了几个高校的常见做法：指导老师评分占40%，评阅老师评分占30%，答辩评分占30%；或者指导老师占50%，评阅占20%，答辩占30%。具体权重可以配置，但业务逻辑是固定的——先分别录入各环节分数，再由系统按照权重自动算出总成绩。成绩计算必须在后端完成，不能靠前端算好了再传过来，否则学生改一下浏览器请求就能自己改分。
这套系统要处理的成绩字段也比一般成绩系统复杂：每个环节除了分数，还要有评语、修改状态、录入时间、是否确认提交。成绩一旦提交就不能随意修改，必须走"申请修改—管理员审批"的流程，这些都是实体表设计时要考虑的字段。
1.3 管理系统三件套：通知、归档、导出
除了成绩录入，学生和导师之间还有大量的交互需求：选题确认、开题报告、中期检查、论文定稿、答辩安排。成绩管理系统如果精力有限，至少要把"答辩分组和通知"做进去——按答辩小组给学生分组，并自动生成答辩时间和地点安排。
归档和导出则是管理员的刚需。答辩结束后，学院要上报最终成绩，系统需要支持按班级、按答辩组筛选导出Excel。如果不做导出功能，管理员还是得回到Excel手工整理，这个系统的价值就少了一半。
这几块需求理清楚之后，后端的表结构、接口设计、前端页面数量基本就定了。后面所有开发工作，本质上都是在为这些业务场景服务。
2. 技术选型不是跟风：为什么是SpringBoot+Vue+MyBatis+MySQL
这套技术组合看起来是Java后端开发的老三样，网上随便一搜就是几十个类似项目。但每个组件在这个系统里承担什么职责，为什么这个组合最适合毕业设计成绩管理，值得掰开讲一下。
2.1 SpringBoot：省去一堆配置的Java后端快捷方式
SpringBoot的核心价值在于"约定大于配置"。用传统的Spring写一个Web项目，要配数据源、配事务管理器、配视图解析器、配JSON序列化，光配置文件就能写几百行；SpringBoot把常用的配置都做成了自动装配，我只需要在pom.xml里加几个依赖，就能起一个能跑的Web服务。
成绩管理系统的后端本质就是个RESTful API服务：接收前端请求，调用服务层处理成绩计算和权限校验，通过MyBatis操作MySQL，最后把JSON数据返回给前端。SpringBoot在这个链路里承担的是最外层的HTTP处理、依赖注入、事务管理。它不需要有多花哨，但必须稳定、上手快、资料多，这对做毕设或者小团队内部系统来说很关键——碰到奇怪的问题，搜索引擎一搜基本都有答案。
2.2 Vue：前端组件化和数据驱动的取舍
前端选择Vue，是因为成绩管理类的后台界面有大量重复的表格、表单、弹窗。用原生JavaScript写DOM操作，改一个状态要手动更新好几个地方；用Vue的数据绑定，前端只要维护好数据模型，界面自动跟着变。比如成绩录入页面，教师在表格里改一个分数，页面底部的"总成绩"列通过计算属性自动重新算出来，不需要写任何"根据DOM事件逐行修改"的代码。
具体到版本，建议用Vue 3配合Element Plus组件库。Element Plus自带表格、对话框、表单校验、消息提示，做完整个前端界面基本不需要自己写CSS布局，省下来的时间可以拿去调后端接口和做测试。
2.3 MyBatis：SQL可控的持久层框架
MyBatis的核心思路是"SQL手写、参数自动绑定"。跟JPA/Hibernate这种全自动ORM框架相比，MyBatis更强调开发者自己对SQL的把控。在成绩汇总这个场景里，我经常要写一些带条件统计、多表联查、动态拼接的SQL（比如"统计某个答辩组所有学生的平均分并按导师分组"），MyBatis的XML映射文件可以非常直观地写这些逻辑，调试起来也方便——SQL就是SQL，复制到Navicat里跑一遍就知道写没写错。
有人会问，为什么不用MyBatis-Plus？标题写的是MyBatis，就先用标准MyBatis实现，这样对SQL基础本来薄弱的新手也是一个很好的锻炼机会。不过我不否认，如果项目后续要加很多简单的单表CRUD接口，MyBatis-Plus确实能省不少模板代码。这套系统里，我仍然建议保持标准MyBatis，核心目的就是让每个SQL都清晰可控、可解释。
2.4 MySQL：这个量级的数据用MySQL绰绰有余
毕业设计成绩管理系统的数据量有多大？一个学院一届毕业生几百人，加上教师、题目、分组、评语，撑死几万条记录。MySQL应对这个量级可以说毫无压力，索引设计合理的情况下查询都是毫秒级。选择MySQL还有一个现实原因：部署简单、免费、生态好，不管是装在本机开发还是部署到服务器，都很成熟。
技术选型的逻辑到这里就很清楚了：这一套组合不是性能最强的，也不是代码最少的，而是"对当前业务最稳、对开发者最友好"的组合。做成绩管理系统，稳定和省心比炫技重要得多。
3. 数据库设计是重头戏：成绩怎么存才不混乱
业务需求明确了，技术栈也定下来了，接下来动数据库。这套系统的核心表我建议分成五张：用户表、学生信息表、题目表、成绩环节表、成绩汇总表。如果能扩展，再加一张答辩分组表。
3.1 用户表与角色设计
用户表（sys_user）是最基础的，字段包括：id、username、password、real_name、role（取值为STUDENT、TEACHER、ADMIN）、email、phone。密码必须加密存储，推荐使用BCrypt加密，不要用MD5——MD5撞库太容易了，毕业设计答辩时有老师拿这个追问，答不上来很尴尬。
学生信息表（student_info）和用户表可以一对一关联，也可以直接合并。我做的时候倾向于单独建一张表，专门存学号、班级、专业、年级这些教务处同步过来的基础信息，避免把这些字段全部塞到用户表里影响认证逻辑。
教师信息不需要单独建表，用sys_user里的role=TEACHER标记即可，额外加一个professional_title字段表示职称，后期导出成绩单时要显示"评阅人：某某（副教授）"。
3.2 成绩表设计：纵表还是横表
成绩存储是设计中最容易纠结的地方。一种做法是"横表"，一张成绩表里直接放三个字段：guide_score、review_score、defense_score；另一种是"纵表"，每个成绩环节单独一条记录，用score_type字段区分是指导分、评阅分还是答辩分。
我在这个项目里推荐纵表。原因有三个：第一，成绩环节可能会调整，比如某个学院今年增加了"小组互评分"，纵表加一条记录就行，横表得改表结构；第二，纵表天然能记录每个环节的录入人和录入时间，审计追踪方便——答辩组看到分数异常时可以准确知道是哪个环节哪个老师录的；第三，汇总统计可以用一行GROUP BY完成，SQL写起来反而更顺手。
成绩表和学生表、题目表的外键关系要建好。成绩记录一定是从属于某个学生和某个题目的，不能出现孤儿数据。在这类表设计上，我的建议是外键要加索引，否则后期多表JOIN查询会越来越慢。
3.3 核心建表SQL参考
以下是成绩管理最核心的几张表，我保留了实际可用的一段SQL供参考：
CREATE TABLE t_score_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', student_id BIGINT NOT NULL COMMENT '学生ID，关联t_student_info', topic_id BIGINT NOT NULL COMMENT '题目ID，关联t_topic', score_type TINYINT NOT NULL COMMENT '环节类型：1-指导教师 2-评阅教师 3-答辩', score DECIMAL(5,1) NOT NULL COMMENT '分数，保留一位小数', comment TEXT COMMENT '评语', recorder_id BIGINT NOT NULL COMMENT '录入人ID', status TINYINT DEFAULT 0 COMMENT '0-草稿 1-已提交 2-已确认', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_student (student_id), KEY idx_topic (topic_id), KEY idx_type (score_type) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩环节记录表'; CREATE TABLE t_score_summary ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, topic_id BIGINT NOT NULL, guide_score DECIMAL(5,1), review_score DECIMAL(5,1), defense_score DECIMAL(5,1), final_score DECIMAL(5,1) COMMENT '加权计算后的总成绩', grade CHAR(2) COMMENT '等级：优/良/中/及格/不及格', summary_time DATETIME, UNIQUE KEY uk_student_topic (student_id, topic_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩汇总表';注意score字段用DECIMAL(5,1)，可以存"90.5"这种常见答辩分。如果哪天需要存两位小数，再改成DECIMAL(5,2)也不迟。
3.4 成绩汇总表的冗余设计：值得吗
t_score_summary这张表其实是冗余表——最终成绩完全可以从t_score_record实时算出来，为什么还要单独存一份？原因很简单：汇总表让查询变得极快，管理员的成绩列表、排名、导出都直接查这张表，不需要每次都做复杂的加权计算。而且汇总表提供了一层数据快照，就算原始成绩单被误改，汇总数据也能帮助追溯当时的总评结果。
这种冗余在数据量小的系统里没有任何问题，反而让代码逻辑清楚很多。需要把握的边界是：写入汇总表的时间点一定要校验，只有当三个环节的成绩都已提交时才允许生成汇总记录，避免出现总成绩算了一半的脏数据。
4. 后端落地：成绩录入、汇总计算和权限控制的关键代码
数据库有了，后端可以开工了。这一部分的重点不是贴所有代码，而是讲清楚三个关键点：登录鉴权怎么做、成绩汇总计算怎么保证准确、接口权限怎么控制。
4.1 基于JWT的登录认证与拦截器
前后端分离的项目，Session方式做登录不太方便，主要问题是跨域和前端独立部署时Cookie不好维护。我采用JWT令牌：用户登录成功后，后端签发一个有效期2小时的JWT返回给前端；前端后续每个请求都在请求头带上Authorization: Bearer token；后端写一个拦截器统一解析token、获取当前用户信息、放行或拒绝。
拦截器里要做两件重要的事：一是解析token失败时返回401让前端跳转登录页；二是把解析出来的用户ID和角色塞进ThreadLocal或者请求属性，方便后续Service层随时拿到当前操作人。ThreadLocal一定要在请求结束后清理，否则线程池复用时会出现"用户A看到用户B数据"的严重问题。这一点我以前就踩过坑，用了Finally代码块清理之后才算安全。
4.2 成绩汇总计算的业务逻辑实现
成绩汇总的核心逻辑在Service层，大概流程是：
- 校验当前学生三个环节的成绩是否都已存在且状态为已提交；
- 从权重配置表中读取当前学院配置的权重比例；
- 加权计算最终成绩，保留一位小数；
- 根据最终成绩映射优（>=90）、良（>=80）、中（>=70）、及格（>=60）、不及格（<60）等级；
- 写入t_score_summary汇总表，同一学生做唯一键冲突时采用更新策略。
这段逻辑要包在事务里，防止写入汇总表成功但更新状态失败导致的数据不一致。Spring的@Transactional注解要加在方法上，回滚规则默认是RuntimeException，如果代码里手动捕获了异常一定要重新抛出，否则事务不会回滚，成绩就悄悄错了。
4.3 成绩修改的权限校验：不是谁都能改
成绩录入接口必须做细粒度权限控制。我的做法是：Service层根据当前登录用户的角色和ID来判断——教师只能录入"指导教师"环节的成绩，评阅教师只能录"评阅"环节，答辩秘书可以录"答辩"环节，管理员可以改所有环节但必须附加修改原因。这么做的目的只有一个：防止角色越权操作。
接口层面的校验用注解实现最方便。自定义一个@RequireRole注解，标注在Controller方法上，拦截器在放行前解析注解要求的角色并与当前用户角色做匹配，不匹配直接返回403。这样权限逻辑收敛在拦截器里，业务方法里不需要写一堆if判断，代码干净很多。
4.4 一个典型的Mapper写法
MyBatis的Mapper层是数据访问的关键。成绩记录这个场景最常用的是条件查询和批量插入，我给出标准MyBatis XML映射里的一个片段：
<select id="selectScoreRecords" resultType="com.example.entity.ScoreRecord"> SELECT id, student_id, topic_id, score_type, score, comment, recorder_id, status, create_time, update_time FROM t_score_record <where> <if test="studentId != null"> AND student_id = #{studentId} </if> <if test="topicId != null"> AND topic_id = #{topicId} </if> <if test="scoreType != null"> AND score_type = #{scoreType} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>使用MyBatis动态SQL，能避免Java代码里拼接SQL的痛苦，也方便后续加筛选条件。注意字段名和实体类属性名的映射关系：如果在application.yml里没配置map-underscore-to-camel-case: true，那查询结果无法自动把student_id映射成studentId，需要手动在resultMap里配。这个细节常常是新手项目跑不通的元凶。
5. 前端联调：Vue页面、路由守卫和接口对接的细节
后端接口写完之后，前端要把这些接口串起来。成绩管理系统的前端界面有几个典型页面：登录页、管理员工作台（学生管理、教师管理、题目管理、权重配置）、教师评阅页（已分配学生列表、录入成绩）、学生成绩查询页。这一章重点说三个容易出问题的点。
5.1 路由守卫：前端权限控制的正确姿势
前端和后端都要做权限控制，但职责不同。后端负责数据安全，前端负责用户体验——不能让学生看到管理员的菜单，也不能让非管理员手动输入URL就跳到管理页面。
Vue Router的全局前置守卫是实现前端路由拦截的常规方案。每次路由跳转前检查是否存在JWT令牌，没有则强制跳到登录页；若有令牌，再根据本地存储的用户角色和路由meta里声明的allowedRoles做匹配，不匹配则重定向到403页。
router.beforeEach((to, from, next) => { const token = localStorage.getItem('access_token') if (!token && to.path !== '/login') { next('/login') } else if (token && to.meta.allowedRoles && !to.meta.allowedRoles.includes(user.role)) { next('/403') } else { next() } })强烈建议配合axios请求拦截器统一在请求头里注入token，以及响应拦截器统一处理401状态码。如果每个请求都手动加header，一旦token字段名变了，改动成本非常大。
5.2 成绩录入页面的交互设计
教师录入成绩的页面是整个前端最重要的页面。我的设计思路是：左侧是分配给我的学生列表，点击某个学生，右侧展示该学生的题名、指导老师信息、论文摘要，以及一个评分表单——分数输入框、评语文本域、提交按钮。
关键交互是"保存草稿"和"确认提交"要分开。教师可能录了一半被打断，或者还需要磨蹭斟酌评语，这时候需要能保存草稿、下次继续编辑。而确认提交之后，后端会把状态置为已提交，页面同时锁定编辑状态。这个交互能有效减少"录完被覆盖"的纠纷，也符合高校教学管理的实际操作习惯。
5.3 前后端联调：跨域问题的常规解法
开发环境中，前端默认跑在http://localhost:5173，后端跑在http://localhost:8080，浏览器会拦截跨域请求。开发阶段最简单的方案是用Vite的代理配置，把前端的/api路径代理到后端的地址，这样前端请求的是同源地址，不触发浏览器跨域拦截。
// vite.config.js export default { server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } }生产部署时前端打包后的静态文件通常由Nginx托管，Nginx配置里同样需要做一个反向代理把/api请求转发给后端Java服务。如果你不想在前后端联调上浪费时间，这是最快跑通整套系统的路径。
6. 部署与踩坑：从本地跑通到放上服务器的典型问题
系统开发完毕，接下来是部署和调试。很多项目死在奇怪的环境问题上——本地跑得好好的，换一台机器全部白屏。这里必须把几个高频问题单独拿出来讲。
6.1 MyBatis驼峰映射失效
什么问题呢？查询结果里user_name是null，但数据库里明明有值。原因就是数据库字段和Java属性没有完成映射。处理方式很简单，在application.yml里加一行：
mybatis: configuration: map-underscore-to-camel-case: true加上之后MyBatis自动把下划线风格的数据库字段映射到驼峰风格Java属性。如果没有加，要么查出来全是null，要么手动配置一大堆resultMap，白白浪费一晚上。这个配置我建议在写第一个查询接口的时候就加上，别等踩坑。
6.2 LocalDateTime序列化格式问题
Java 8的LocalDateTime如果直接交给Spring Boot默认的Jackson序列化，前端拿到的很可能是"2025-06-02T14:30:00"这种带T的ISO格式，看着非常突兀，提交到后端做时间解析时也容易出错。解决办法是在application.yml里做全局配置：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8这样前端拿到的就是"2025-06-02 14:30:00"，符合国内用户的时间阅读习惯。时区配置也不能漏，否则部署在服务器上时间会差8小时。
6.3 前端history路由刷新404
前端用VueRouter的history模式，打包部署到Nginx后，用户在system页面刷新一下，居然404了。原因是history模式下URL不携带#号，Nginx找不到对应的静态文件就返回404。需要在Nginx配置里加一个try_files指令，让除静态文件外的所有请求都回退到index.html入口：
location / { root /opt/score-system/dist; index index.html; try_files $uri $uri/ /index.html; }这个问题如果不提前知道，部署阶段能卡住一整天，而且特别影响答辩演示——演示时刷新了一下直接白屏404，心态容易崩。
6.4 事务不生效的隐蔽场景
前面提过@Transactional必须通过代理调用才能生效。有一个隐蔽的坑：在同一个类里，方法A调用方法B，方法B上有@Transactional，此时事务不生效，因为Spring的代理不会拦截类内部方法调用。解决办法是把需要事务的方法拆到另一个Service类中，或者通过ApplicationContext重新获取代理对象。解决这类诡异问题的时候，打断点和日志输出是最高效的排查手段，单纯盯着代码很难看出问题。
7. 模拟数据演示与验收：这套系统到底能不能用
代码写完、服务跑通，最关键的一步是用真实场景的模拟数据把所有功能串一遍。我拿一批模拟数据做了一次完整验收，这里把过程完整还原出来。
7.1 造一批覆盖各种情况的模拟数据
准备了三名教师（一位做指导老师、一位做评阅老师、一个答辩秘书角色），五名学生，每名学生分配一个毕设题目。其中两名学生的三个成绩环节都已提交，一名学生只录了指导分和评阅分，一名学生三个环节都没录，还有一个学生答辩分为空。这五名学生覆盖了正常提交、部分提交、完全未提交三种状态，足以验证系统各流程分支。
造数据有一个建议：不要全部用"成绩优秀"的数据，一定要包含几个及格边缘的、分数悬殊的，才能验证成绩汇总计算的边界情况。比如某个学生指导分90、评阅分70、答辩分65，最终加权成绩会落在哪个区间，需要人工预先算好，再用系统结果比对。
7.2 端到端验收：从登录到成绩导出
验收流程我按以下步骤走了一遍：
- 用管理员账号登录，导入学生名单和题目分配表，校验列表显示正确。
- 用指导教师账号登录，确认只看到自己名下的两名学生，录入指导成绩并提交。
- 切换评阅教师、答辩秘书账号，分别录入各自环节分数。
- 回到管理员界面，打开成绩汇总页面，确认三名学生已经算出总成绩，其中部分提交的学生提示"成绩未完整提交"。
- 按答辩组筛选，导出Excel，核对导出文件中的分数与数据库一致。
- 用学生账号登录，确认只能看到自己的最终成绩和评语，看不到任何其他学生的信息。
这套流程跑下来，整个系统的业务闭环就验证完整了。这里要特别提醒Excel导出后的格式问题：分数列千万别出现科学计数法，导出时把分数列格式设为文本或者保留一位小数，否则Excel里90.0显示成9E+01就闹笑话了。
7.3 验收清单：答辩之前必须逐项勾选
功能验收之外，还要准备一份符合毕设答辩风格的验收清单：
- 项目能干净地启动和关闭，无控制台报错，无端口占用。
- 数据库初始化SQL可以一键执行，表结构注释完整，关键字段有索引。
- 登录、退出、权限拦截的边界场景都测过：未登录访问接口返回401、学生访问管理员接口返回403。
- 成绩计算逻辑有单元测试或人工核对记录，权重比例调整后汇总结果能自动更新。
- 前后端打包产物能部署到同一台服务器，静态资源和API请求都能正常工作。
- 项目文档里包含运行说明、数据库设计说明、接口说明。先把这几项逐条核对完，再考虑加分功能。
7.4 可扩展的升级方向
系统做完基本功能后，有几个方向值得继续扩展。一是文件上传：毕业设计论文、任务书、查重报告都是文件，给成绩表加一个附件管理功能，默认不传文件就不允许提交成绩，能一步到位实现"成绩和材料绑定"。二是消息通知：成绩确认提交后自动发送邮件或站内信给指导教师和答辩秘书，减少线下沟通成本。三是成绩分析报表：用ECharts把各班成绩分布、各导师平均分做成图表，给教学秘书做质量分析用。
我的体会是，这套系统真正的难点不在于技术，而在于你愿不愿意把业务流程一遍一遍想清楚。成绩管理系统最怕的不是性能瓶颈，而是业务边界模糊导致的数据混乱。把需求想透、把权限管住、把成绩计算逻辑写明确，系统自然就稳了。如果你正在做类似的毕设题目，希望这篇文章能帮你少走一点弯路。
