简介：这份资源是《基于SpringBoot学生成绩管理系统的设计与实现》完整毕业设计文档，面向计算机相关专业学生及JavaWeb初学者，用于解决课程设计、毕业设计选题与系统开发参考问题。文档围绕管理员、教师、学生三角色权限体系展开，涵盖院系管理、考试成绩管理、成绩登记与查询等核心业务。压缩包共1个docx文件，约1.14MB，内容结构完整，包含绪论、系统分析、概要设计、数据库表结构设计、各角色功能实现及系统测试等章节，并附有结论、参考文献与致谢。读者可从中获取基于SpringBoot、MySQL与JavaWeb技术栈的完整设计方案，包括可行性分析、需求分析、功能模块划分、数据库概念模型与表结构设计，以及登录、信息维护、成绩录入等模块的实现思路和单元测试、集成测试方法。目前已有8554人学习下载，适合需要撰写论文或搭建同类管理系统的读者参考借鉴。
1. 学生成绩管理系统：为什么“能跑通”和“能交付”之间隔着一整套设计
每年毕业季，基于 SpringBoot 的学生成绩管理系统都是高频选题。原因很直接：业务逻辑不复杂，数据关系清晰，答辩时容易讲清楚。但真正动手做过的人都知道，从“能跑通”到“能交付”之间，差的不是几行代码，而是一整套设计决策——成绩录入时并发冲突怎么处理、批量导入几千条数据时事务怎么控制、不同角色看到的成绩视图怎么隔离、期末成绩算错了能不能追溯。
这个系统面向三类人：教务管理员负责课程与班级维护，教师负责成绩录入与提交，学生负责查询个人成绩。核心难点不在增删改查，而在成绩数据的准确性、权限的颗粒度、以及批量操作时的性能与一致性。如果你正在做这个选题，或者准备把它作为 SpringBoot 实战练手项目，下面这套从建表到部署的完整路径可以直接参考。
2. 从成绩单到数据库：表结构设计与 SpringBoot 工程骨架
2.1 成绩管理系统的四张核心表与字段取舍
学生成绩管理系统的数据模型看似简单，但字段设计直接决定后续查询效率和扩展空间。我一般会先画清楚实体关系：学生、课程、班级、成绩记录，四张表就能撑起核心业务。
学生表student的关键字段：学号student_no作为业务主键（唯一索引），姓名、性别、班级 ID、入学年份。这里有个容易翻车的地方——用自增 ID 做学号。学号是业务标识，一旦用自增 ID，转专业或休学复学时学号变更会引发成绩记录关联断裂。所以学号必须独立于主键，建唯一索引。
课程表course：课程编码、课程名称、学分、授课教师 ID、学期标识。学期标识建议用2024-2025-1这种格式，而不是两个字段拼。成绩表score是核心：学生 ID、课程 ID、平时成绩、期末成绩、总评成绩、录入教师 ID、录入时间、状态（草稿/已提交/已归档）。总评成绩不要存死值，用计算字段或触发器维护，否则平时成绩修改后总评对不上。
班级表class相对简单：班级名称、年级、专业、辅导员。四张表的关系用外键约束还是应用层维护？我的血泪经验是：毕设项目用应用层维护，数据库不建外键。原因很现实——批量导入成绩时外键检查会拖慢速度，而且删除课程时级联约束容易导致误删成绩记录。
注意：成绩表一定要加
(student_id, course_id, semester)的联合唯一索引，防止同一学生同一学期同一课程重复录入。
2.2 用 Spring Initializr 搭出可运行的最小骨架
工程骨架不需要花哨，但依赖选错后面改起来很痛苦。我一般用 Spring Initializr 生成，选 Spring Boot 2.7.x 版本（3.x 对 JDK 版本要求高，毕设环境不一定跟得上）。依赖勾选：Spring Web、MyBatis Framework、MySQL Driver、Lombok、Spring Boot DevTools。
# 用 curl 直接生成工程骨架，避免浏览器操作 curl https://start.spring.io/starter.zip \ -d type=maven-project \ -d language=java \ -d bootVersion=2.7.18 \ -d groupId=com.example \ -d artifactId=score-manager \ -d name=score-manager \ -d packageName=com.example.score \ -d dependencies=web,mybatis,mysql,lombok,devtools \ -o score-manager.zip unzip score-manager.zip -d score-manager这段命令生成的是标准 Maven 工程。bootVersion指定 2.7.18 是因为这个版本稳定且与大多数毕设环境兼容。dependencies里 MyBatis 而不是 JPA，原因是成绩查询涉及多表联查和动态条件，MyBatis 的 XML 映射更直观，答辩时也容易讲清楚 SQL 逻辑。
生成后先改application.yml，把数据源和 MyBatis 配好：
spring: datasource: url: jdbc:mysql://localhost:3306/score_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.score.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case这个配置必须开，否则数据库的student_no映射不到 Java 的studentNo，查出来全是 null。serverTimezone不配的话，MySQL 8 会报时区错误，成绩录入时间会差 8 小时。
2.3 分层结构：Controller、Service、Mapper 的职责边界
分层不是形式主义，是为了让成绩计算逻辑有地方放。我的习惯是：Controller 只做参数校验和视图返回，Service 写业务规则（比如总评成绩计算、权限判断），Mapper 只负责 SQL 映射。
成绩计算放在 Service 层的一个典型场景：总评 = 平时成绩 × 0.3 + 期末成绩 × 0.7。这个比例可能因课程而异，所以要在课程表加平时比例和期末比例两个字段，Service 里动态读取。如果放在 Controller 里算，换一门课就得改代码；放在 Mapper 里用 SQL 算，比例调整时 SQL 要重写。
@Service public class ScoreService { @Autowired private ScoreMapper scoreMapper; @Autowired private CourseMapper courseMapper; @Transactional(rollbackFor = Exception.class) public void batchImport(List<ScoreDTO> list) { for (ScoreDTO dto : list) { Course course = courseMapper.selectById(dto.getCourseId()); BigDecimal total = dto.getDailyScore() .multiply(course.getDailyRatio()) .add(dto.getExamScore().multiply(course.getExamRatio())); dto.setTotalScore(total.setScale(1, RoundingMode.HALF_UP)); } scoreMapper.batchInsert(list); } }@Transactional的rollbackFor = Exception.class很关键。默认只回滚 RuntimeException，如果导入时抛了受检异常，前面插入的数据不会回滚，成绩表就脏了。setScale(1, RoundingMode.HALF_UP)是保留一位小数并四舍五入，成绩场景不能用默认的银行家舍入。
3. 成绩录入与查询：MyBatis 动态 SQL 和批量操作的性能边界
3.1 多条件成绩查询的动态 SQL 写法
成绩查询页面通常有多个筛选条件：学期、班级、课程、学生姓名。用 MyBatis 的<where>和<if>标签拼动态 SQL 是最稳妥的做法。
<select id="selectByCondition" resultType="com.example.score.entity.ScoreVO"> SELECT s.id, st.student_no, st.name AS studentName, c.course_name, s.daily_score, s.exam_score, s.total_score FROM score s JOIN student st ON s.student_id = st.id JOIN course c ON s.course_id = c.id <where> <if test="semester != null and semester != ''"> AND s.semester = #{semester} </if> <if test="classId != null"> AND st.class_id = #{classId} </if> <if test="courseId != null"> AND s.course_id = #{courseId} </if> <if test="studentName != null and studentName != ''"> AND st.name LIKE CONCAT('%', #{studentName}, '%') </if> </where> ORDER BY st.student_no ASC LIMIT #{offset}, #{pageSize} </select><where>标签会自动处理第一个条件前的 AND，不用手写WHERE 1=1。LIKE CONCAT('%', #{studentName}, '%')用#{}而不是${}，防止 SQL 注入。分页用LIMIT offset, pageSize，offset 由前端页码换算。
这里有个性能坑：学生姓名模糊查询在数据量上万后会很慢。如果毕设数据量不大（几百条），无所谓；但如果要演示性能优化，可以在student.name上加索引，或者改用前缀匹配LIKE CONCAT(#{studentName}, '%')。
3.2 批量导入成绩：事务控制与插入优化
教师录入成绩最怕的是导入到一半失败，前面插进去的数据成了脏数据。批量导入必须在一个事务里完成，同时要注意 MySQL 的max_allowed_packet限制。
@Transactional(rollbackFor = Exception.class) public void batchImport(List<ScoreDTO> list) { // 分批插入，每批 500 条，避免单条 SQL 过大 int batchSize = 500; for (int i = 0; i < list.size(); i += batchSize) { int end = Math.min(i + batchSize, list.size()); List<ScoreDTO> batch = list.subList(i, end); scoreMapper.batchInsert(batch); } }对应的 Mapper XML：
<insert id="batchInsert" parameterType="java.util.List"> INSERT INTO score (student_id, course_id, semester, daily_score, exam_score, total_score, teacher_id) VALUES <foreach collection="list" item="item" separator=","> (#{item.studentId}, #{item.courseId}, #{item.semester}, #{item.dailyScore}, #{item.examScore}, #{item.totalScore}, #{item.teacherId}) </foreach> ON DUPLICATE KEY UPDATE daily_score = VALUES(daily_score), exam_score = VALUES(exam_score), total_score = VALUES(total_score) </insert>ON DUPLICATE KEY UPDATE配合联合唯一索引，实现“存在则更新，不存在则插入”。这样教师重复导入同一批成绩时不会报错，而是覆盖旧值。batchSize设 500 是经验值，太大容易触发max_allowed_packet错误，太小则事务提交次数多影响性能。
注意：
ON DUPLICATE KEY UPDATE在 MySQL 中会消耗自增 ID，如果 score 表用自增主键，批量导入后 ID 会跳号。毕设场景不影响使用，但要知道这个现象。
3.3 成绩修改的并发问题与乐观锁方案
两个教师同时修改同一条成绩记录时，后提交的会覆盖先提交的。这个问题在毕设答辩时经常被问到。解决方案是加版本号字段version，用 MyBatis 的乐观锁插件或手写 SQL 控制。
UPDATE score SET daily_score = #{dailyScore}, exam_score = #{examScore}, total_score = #{totalScore}, version = version + 1 WHERE id = #{id} AND version = #{version}Service 层判断受影响行数，如果为 0 说明版本号不匹配，抛出“成绩已被他人修改，请刷新后重试”。这个方案比悲观锁（SELECT ... FOR UPDATE）更适合成绩录入场景，因为并发冲突概率低，乐观锁不会阻塞查询。
4. 权限与视图隔离：不同角色看到不同成绩的落地方式
4.1 基于拦截器的角色权限控制
学生成绩管理系统至少三种角色：管理员、教师、学生。权限控制不需要上 Spring Security（毕设项目配置复杂容易翻车），用拦截器 + Session 就能搞定。
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String uri = request.getRequestURI(); HttpSession session = request.getSession(); User user = (User) session.getAttribute("currentUser"); if (user == null) { response.sendRedirect("/login"); return false; } // 学生只能访问查询接口 if ("student".equals(user.getRole()) && uri.startsWith("/score/edit")) { response.sendError(403, "无权访问"); return false; } return true; } }注册拦截器时排除登录页和静态资源：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/css/**", "/js/**", "/images/**"); } }excludePathPatterns里必须排除静态资源，否则登录页的 CSS 和 JS 会被拦截，页面样式全丢。这个坑我踩过，排查了半天以为是前端问题。
4.2 学生只能看自己成绩：数据级权限的 SQL 拼接
角色权限控制的是“能不能访问某个接口”，数据级权限控制的是“能看到哪些数据”。学生查询成绩时，SQL 必须自动加上student_id = 当前用户ID的条件。
public List<ScoreVO> queryScores(ScoreQuery query, User currentUser) { if ("student".equals(currentUser.getRole())) { query.setStudentId(currentUser.getStudentId()); } return scoreMapper.selectByCondition(query); }在 Mapper XML 里加一个<if test="studentId != null"> AND s.student_id = #{studentId} </if>。这样教师查全部，学生只查自己，同一套 SQL 复用。关键是studentId不能从请求参数取，必须从 Session 里的用户信息取，否则学生改一下 URL 参数就能看到别人的成绩。
4.3 教师提交成绩后的状态流转
成绩录入不是一锤子买卖，需要状态管理：草稿、已提交、已归档。教师录入时是草稿，确认无误后提交，提交后学生才能查到。管理员可以归档，归档后任何人不能修改。
状态流转用枚举控制：
public enum ScoreStatus { DRAFT("草稿"), SUBMITTED("已提交"), ARCHIVED("已归档"); private final String label; ScoreStatus(String label) { this.label = label; } public String getLabel() { return label; } }Service 层在修改成绩前检查状态：
public void updateScore(Score score) { Score existing = scoreMapper.selectById(score.getId()); if (existing.getStatus() == ScoreStatus.ARCHIVED) { throw new BusinessException("已归档成绩不可修改"); } if (existing.getStatus() == ScoreStatus.SUBMITTED && !"admin".equals(currentUser.getRole())) { throw new BusinessException("已提交成绩需管理员退回后才能修改"); } scoreMapper.updateById(score); }这个状态机不复杂，但答辩时能讲出“为什么需要状态”比只讲增删改查高一个层次。常见追问是“提交后教师发现录错了怎么办”，答案是管理员退回，状态回到草稿。
5. 避坑与排查：成绩管理系统开发中最容易翻车的五个点
5.1 中文乱码：从数据库到页面的全链路排查
现象：学生姓名在页面显示为??或æŽå。原因通常有三层：数据库字符集不是 utf8mb4、JDBC 连接没指定编码、Tomcat 响应编码没配。解决顺序是先从数据库查起：
SHOW VARIABLES LIKE 'character_set%'; -- 确认 character_set_server 和 character_set_database 都是 utf8mb4然后检查 JDBC URL 是否带useUnicode=true&characterEncoding=utf8。最后在application.yml加server.servlet.encoding.charset=utf-8和force=true。三层都对了才不会乱码。
5.2 批量导入时事务不回滚
现象：导入 100 条成绩，第 50 条格式错误抛异常，但前 49 条已经进库了。原因：@Transactional默认只回滚RuntimeException，如果代码里抛的是Exception或自定义的受检异常，事务不会回滚。解决：注解写成@Transactional(rollbackFor = Exception.class)，并且确保异常没有被 catch 后吞掉。
5.3 分页查询总数不对
现象：成绩列表显示共 100 条，但翻到第 3 页就没数据了。原因：分页查询的COUNTSQL 和列表 SQL 的WHERE条件不一致，通常是 COUNT 语句忘了加动态条件。解决：把WHERE条件抽成 SQL 片段，用<sql id="queryCondition">定义，列表和 COUNT 都引用同一个片段。
5.4 成绩计算精度丢失
现象：平时 85.5 × 0.3 + 期末 92.3 × 0.7，算出来是 90.25999999999999。原因：用double做小数运算。解决：金额和成绩一律用BigDecimal，并且除法运算必须指定精度和舍入模式，否则除不尽时会抛ArithmeticException。
5.5 部署后静态资源 404
现象：本地跑得好好的，打成 jar 部署到服务器后 CSS 和 JS 全部 404。原因：SpringBoot 默认从classpath:/static/加载静态资源，如果前端文件放在webapp目录下，打成 jar 后不会被包含。解决：把静态资源统一放到src/main/resources/static/下，或者用 Nginx 单独托管前端文件。
6. 从能跑到能答辩：成绩管理系统的验证清单与演示技巧
6.1 用 Postman 做接口冒烟测试的五个必测场景
答辩前我会用 Postman 把核心接口跑一遍，重点测五个场景：正常登录返回 Session、学生查自己成绩只返回本人数据、教师批量导入 500 条成绩耗时在 3 秒内、重复导入同一批成绩不报错且数据被覆盖、已归档成绩修改返回业务异常。这五个场景覆盖了权限、性能、幂等和状态机，答辩老师问到的概率最高。
# 用 curl 快速验证登录和查询接口 curl -c cookies.txt -X POST http://localhost:8080/login \ -d "username=student001&password=123456" curl -b cookies.txt http://localhost:8080/score/my?semester=2024-2025-1第一条命令把 Session Cookie 存到cookies.txt，第二条带上 Cookie 请求成绩查询。如果返回的 JSON 里只有 student001 的成绩，说明数据级权限生效了。
6.2 答辩演示的数据准备与操作顺序
演示最怕现场翻车。我的习惯是提前准备三份数据：一份干净的初始数据（用于演示录入）、一份完整的历史数据（用于演示查询和统计）、一份边界数据（比如 0 分、缺考、缓考）。演示顺序按“管理员建课 → 教师录成绩 → 学生查成绩 → 管理员归档”走一遍完整流程，中间穿插一次批量导入和一次重复导入，展示幂等性。
统计图表是加分项。用 ECharts 做一个班级成绩分布柱状图，数据从/score/statistics?classId=1接口取。这个接口的 SQL 用GROUP BY score_range分段统计，比直接返回原始数据更有展示效果。
6.3 一个我反复用的验证习惯
每次改完 Mapper XML 或 Service 逻辑，我不会直接启动整个项目点页面，而是先跑一个最小单元测试：
@SpringBootTest class ScoreServiceTest { @Autowired private ScoreService scoreService; @Test void testBatchImport() { List<ScoreDTO> list = buildTestData(10); scoreService.batchImport(list); List<ScoreVO> result = scoreService.queryByCourse(1L, "2024-2025-1"); assertEquals(10, result.size()); } }这个习惯帮我省了很多时间。页面点一次要启动 Tomcat、等前端加载、登录、翻页，而单元测试几秒就跑完。尤其是改 SQL 的时候，单元测试能直接告诉我映射有没有问题，不用在浏览器和 IDE 之间来回切。
做这个系统最大的教训是：不要等到最后才联调数据库和前端。我一般建完表就先写一个 Mapper 测试，确认增删改查通了再写 Service，最后才写 Controller 和页面。这样每一层都是验证过的，出问题能快速定位是哪一层的锅。希望帮到你。
本文还有配套的精品资源，点击获取
