每年到了评奖评优和毕业资格审核的时候，各高校的第二课堂学分核算都是一场"人肉大战"。学生拿着各种活动证明、证书复印件找辅导员签字，辅导员对着纸质表格逐个核对，学院教务再汇总成Excel，中间漏一条、填错一列都是常事。我接手这个Spring Boot第二课堂素质学分管理系统时，目标很明确：把活动发布、报名签到、学分申报、审批认定、统计排名这一整套流程，从线下搬到线上，让学分数据在各角色之间自动流转，而不是靠人力来回搬运。
这个系统的核心价值在于它不是一个简单的增删改查，而是围绕"学分认定"这条业务主线，设计了完整的多角色审批链和学分换算规则。对正在做毕业设计、或者想拿这个方向练手Spring Boot的同学来说，它的业务复杂度刚刚好——比单表CRUD有营养，又不像电商秒杀那样需要高并发架构，非常适合用来展示Spring Boot + MyBatis-Plus + Vue这套主流技术栈的完整落地能力。下面我把整个系统的设计与实现过程拆开讲，包括业务建模思路、数据库设计、核心流程的实现细节，以及我在实际开发中踩过的坑。
1. 先搞懂业务：第二课堂学分管理的真实痛点在哪
很多人拿到这种题目第一反应就是"做个学生管理系统的换皮"，上来就画用户表、活动表、报名表，结果做完发现根本不贴合实际。第二课堂和第一课堂最大的区别在于：第一课堂的学分是教学计划定死的，课程结束给成绩就行；而第二课堂的学分来源极其分散，包括社团活动、志愿服务、学科竞赛、讲座报告、文体活动、社会实践等等，每个类别有不同的认定标准，每项活动有不同的分值上限，最终还要汇总到每个学生每学年必须修满的学分额度里。
1.1 线下管理到底乱在哪里
我在前期调研时归纳了三个核心痛点。第一个是数据分散：活动发布在QQ群、报名表在共享文档、签到在线下纸质名单、学分记录在Excel，一条完整的数据链被切成了四五个孤岛，每次统计都要重新拼接。第二个是标准不统一：同样是参加一次讲座，A学院认定0.2学分，B学院认定0.5学分，学生跨学院参加活动时经常产生争议。第三个是追溯困难：学期末学生说"我参加过这个活动但没记录"，管理员根本无从查证，纸质材料又容易丢失。
1.2 系统要解决的核心问题
所以这个系统本质上是在做一件事：建立一套统一的学分认定标准和可追溯的审批流程。具体拆解为四个子系统目标：
- 对学生：在线查看活动、报名参加、提交学分申报材料、实时查看学分明细和进度。
- 对活动组织方（社团、学生会、学院）在线发布活动、管理报名名单、录入签到记录。
- 对审核人员（辅导员、学院管理员）在线审核学分申报，支持通过、驳回、退回修改等操作。
- 对系统管理员：统一维护学分规则、活动分类、用户权限，以及最后的学分汇总统计和导出。
这个定位想清楚之后，后面所有设计都围绕"学分如何被认定"这一条主线展开，而不是把每个模块做成孤立的CRUD。比如活动模块，它不只是发布一个活动，而是要支撑后续的签到生成、学分申报引用；学分规则模块也不是简单的数值配置，它决定了申报时系统能不能自动计算分值、能不能防止超额申报。
2. 技术选型和项目骨架：为什么Spring Boot是这类系统的合理答案
技术选型如果只看流行度，很容易陷入"什么都想用"的误区。我最终确定的主技术栈是：Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis + Vue 3 + Element Plus。这个组合在现阶段的高校毕设和企业小型项目中都非常主流，资料多、上手快、坑也好搜。
2.1 关键组件选择的理由
- Spring Boot：简化了Spring的大量XML配置，内嵌Tomcat让部署变成"一个jar包跑起来"，这对后续服务器部署是极大的便利。选2.7而不是3.x，主要考虑的是MyBatis-Plus、Shiro这些生态组件的兼容性更稳定，避免在版本适配问题上浪费毕业设计的时间。
- MyBatis-Plus：单表CRUD基本不需要写SQL，自带分页插件和代码生成器，能把大量重复的Dao层工作省掉。但多表关联统计仍然需要手写SQL，这点要心里有数。
- Redis：这个项目里Redis不是摆设。活动报名时要防止超报、学分统计结果要缓存、验证码和Token也要存，它的用武之地非常明确。
- JWT + 拦截器：因为前端是前后端分离的Vue项目，用JWT做无状态登录认证比Session更契合，拦截器统一校验Token和角色权限。
2.2 项目分层与目录结构
我采用的是经典的四层架构：Controller（接口层）、Service（业务层）、Mapper（数据访问层）、Entity（实体层），另外加了一个Config包放配置类、一个Common包放统一返回结果和异常处理。
com.example.secondclass ├── controller // 接口层，只做参数接收和结果封装 ├── service // 业务层，核心逻辑都在这层 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto // 前端交互的传输对象，避免直接暴露实体 ├── config // 配置类：MyBatis-Plus分页、跨域、JWT拦截器 ├── common // 统一返回结果、业务异常、常量定义 └── utils // 工具类：JWT工具、Excel导入导出工具一个容易被忽略但很重要的实践是在Controller层和Service层都做参数校验。前端校验只是用户体验，真正防脏数据必须靠后端。比如学号格式、学分数值的范围、时间日期的先后顺序，Service层必须兜底校验，否则一条非法数据就能让统计报表全乱。
2.3 统一返回结果和异常处理
前后端分离项目最怕接口返回格式不统一，前端拿到数据还得猜。我定义了一个Result<T>类，统一包含code、message、data三个字段，配合全局异常处理器@RestControllerAdvice，保证任何异常都返回结构一致的JSON。这样前端axios的响应拦截器只需要判断一次code即可，开发效率提升很明显。
3. 数据库设计：表的数量不在多，而在关系闭环
这套系统我最终设计了12张核心表，覆盖用户、活动、学分规则、申报审批、签到、公告六大块。数据库设计的核心原则是：凡是需要追溯的数据，必须保留状态字段和关联外键，绝不能把审批结果直接改成一条新记录覆盖掉原记录。
3.1 用户角色权限设计
用户表sys_user是最基础的表，包含user_id、username、password、real_name、student_no、role_type、college_id、grade等字段。角色我用了role_type字段区分，取值是STUDENT、ORGANIZER（组织者）、AUDITOR（审核人）、ADMIN四种，而不是单独建五张用户表——对这类微型系统来说，RBAC的权限模型用角色字段加拦截器就能实现，没必要引入Spring Security的复杂机制。
提示：密码必须加密存储，推荐用BCrypt。我见过太多毕设把密码明文存数据库，这是安全意识的硬伤，答辩时被问到会很被动。
3.2 学分规则表的灵活设计
第二课堂学分管理的难点在于规则会变。今年讲座0.2分，明年可能改成0.3分；今年要求志愿时长满20小时，明年可能调整。所以学分规则不能写死在前端或Java代码里，必须做成配置表credit_rule，字段包括：规则ID、活动分类、项目名称、单次学分上限、每学期认定上限、是否需要证明材料、有效状态。
举个例子，学科竞赛类奖项的学分会因为获奖等级不同而不同，我在规则表里用rule_key区分competition_national_first、competition_school_second这样的细粒度配置，审核时按规则取值，系统自动带入申报表，避免学生自己乱填分数。
3.3 申报审批表的状态流转设计
credit_apply是整张关系网的核心，它记录了每一次学分申报的完整信息：申报人ID、关联活动ID、关联规则ID、申报学分、证明材料URL、审批状态、审批人ID、审批意见、审批时间。审批状态我用status字段表示，取值为：0待审核、1已通过、2已驳回、3已撤回。
把状态设计成整数枚举有几个好处：一是数据库查询条件简单，WHERE status = 0就能查出待办；二是后续扩展状态方便，在中间插入新状态也不会破坏已有逻辑。审批通过之后我还会写入一条credit_record明细记录，这相当于会计里的"凭证"——学分统计表可以随时从明细表重新汇总，不怕数据被误改。
4. 核心业务流程的实现：活动发布、报名签到、学分申报和审批闭环
业务逻辑是这个系统的重头戏，也是拉开毕设档次的地方。下面按一条完整的业务链路——从活动发布到学分认定入库——逐步拆解实现要点。
4.1 活动发布和报名防超员
活动表activity保存活动基本信息，包括activity_name、activity_type、start_time、end_time、location、capacity（人数上限）、credit_rule_id、publisher_id、status。发布时要注意校验时间：活动结束时间必须晚于开始时间，活动学分规则必须是有效状态。
报名接口最核心的问题是防超员。设想这样一个场景：50人的活动，第50个人和第51个人同时点击报名，如果代码是先查人数再insert，两个请求可能都查到当前49人，然后都插入成功，实际报名人数变成51人。我在实现时用了两种方式兜底：
第一种是乐观锁，在活动表加version字段，更新报名人数时用UPDATE activity SET current_count = current_count + 1, version = version + 1 WHERE activity_id = ? AND current_count < capacity AND version = ?，影响行数为0则说明报名失败。第二种是Redis预扣减，活动发布时把capacity写入Redis，报名前用DECR命令预扣，返回负数说明名额已满。两个方案我最终都实现了，Redis方案响应更快，但MySQL乐观锁方案不依赖额外组件、更稳。毕设演示时推荐主用乐观锁，逻辑简单也好解释。
4.2 签到与会话管理
签到是学分认定的重要依据，但实现方式要根据场景选择。我设计了两种签到方式：一是活动组织者线下扫码或按名单代签，二是学生提交报名号+学号自助签到。签到时生成sign_record记录，同时更新活动表的签到人数。
这里有一个细节：签到必须在活动时间窗口内进行。我在Service层加了时间判断，活动开始前30分钟才开放签到，活动结束后1小时关闭签到。为什么是30分钟而不是直接开放？因为实际场景里组织者需要提前到场布置，提前太早签到会产生"人来没来都能签"的漏洞。
4.3 学分申报和审批的流转
学生参加完活动、拿到签到记录后，在系统里发起学分申报。申报时前端传入活动ID，后端自动带出活动信息和对应的学分规则，计算默认学分，学生只需补充证明材料图片链接。提交后生成credit_apply记录，状态为0待审核。
审批接口是我觉得最值得讲解的部分。审核人调auditApply(applyId, result, opinion)接口，Service层要先做一系列校验：
- 该申请的状态必须是
0待审核，防止重复审批； - 当前登录用户必须是该学院有审核权限的人；
- 如果通过，要检查该学生在本学期此类别下已获学分加上本次申报学分是否超过规则上限，超了就自动拦截并提示"超出该类目学期上限"。
这第三点是最容易被忽略的。如果不做超额校验，学生可以反复申报同类低价值活动堆学分，期末统计时数据全部超标，整个系统就失去了管理意义。通过后在同一个事务里执行两步：更新credit_apply状态为1，插入credit_record明细记录。这两个操作必须放在@Transactional里，否则会出现状态改了但明细没生成的脏数据。
5. 开发中反复踩的坑：权限、事务、Excel和联调的实战教训
这部分是实际操作中积累的，很多问题不到真实开发时根本发现不了。
5.1 事务失效：同一个类内部调用@Transactional
在审批通过、创建学分明细的场景里，我最初把新增credit_record的代码提取成了本类的一个私有方法并加上@Transactional，结果发现明细经常不插入，后来排查才知道：Spring的事务代理基于AOP，同类内部方法调用不走代理，注解不生效。解决方式有两个：一是直接把事务注解加在对外暴露的公共方法上，让整个审批逻辑在一个事务里；二是把明细插入逻辑拆到另一个@Service类中调用。我推荐第一种，代码更直观，事务边界也更清晰。
5.2 权限控制的完整链路
这个系统涉及四种角色，权限控制必须在三层同时做：前端路由守卫控制页面跳转，后端拦截器校验是否登录和Token是否有效，接口内部用注解或代码判断角色权限。只有前端控制的话，随便用Postman调接口就能绕过，这是毕设答辩的高频翻车点。
我实现了自定义注解@RequireRole配合拦截器使用，在Controller方法上标注@RequireRole({"AUDITOR", "ADMIN"})，拦截器解析Token后判断当前用户角色是否在许可集合中。这样做的好处是权限声明在接口签名上，读代码的人一眼就能看出接口的访问约束。
5.3 Excel导入导出的性能问题
期末批量导入学生名单、导出学分汇总表是这个系统使用频率最高的功能之一。我用的是EasyExcel而不是传统的Apache POI，因为EasyExcel的流式读取对内存更友好，几千条数据不会OOM。但EasyExcel也有个坑：实体类字段必须加@ExcelProperty注解绑定列名，而且日期格式要用@DateTimeFormat明确指定，否则导入时全部变成数字乱码。
另外一个经验：如果数据量超过2000条，不要在请求线程里同步解析Excel。可以先用Job异步处理、返回"导入中"的状态，用户通过轮询接口获取结果。毕设如果数据量不大，同步处理问题不大，但我会在代码里把处理逻辑独立成一个方法，方便后续改造。
5.4 前后端联调的跨域和字段命名
Spring Boot后端默认不允许跨域请求，Vue开发服务器跑在8080端口，后端在9090端口，需要配置CORS。我写了一个WebMvcConfigurer的配置类，放行了所有来源和所有请求头，同时allowedMethods必须加上OPTIONS，否则前端发application/json请求时预检直接失败。前端拿到的JSON字段是下划线风格还是驼峰风格，前后端一定要提前约定好。我让MyBatis-Plus开启了map-underscore-to-camel-case，数据库字段activity_name自动映射为activityName，前端少了很多转换工作。
5.5 分页统计的SQL优化
学分汇总页面需要按学院、年级、班级维度统计每个人的总分，最初我用MyBatis-Plus的QueryWrapper拼条件，结果关联查询时出现重复计数——因为一个学生可能有多条活动记录参与联表。最后改成手写XML里的GROUP BY聚合查询，统计逻辑才正确。这里要提醒的是：聚合统计类SQL不要偷懒用ORM的API硬拼，多表联查时先明确每张表的粒度，再确定分组维度，否则数据翻倍查出来根本没法用。
6. 从"能跑"到"能用"：测试数据设计与后续扩展思路
这个系统做完之后，我还专门花了两天做了一件事：造了一套真实感很强的模拟数据。包括3个学院、4个年级、120个学生、20多个活动、几百条报名和申报记录，模拟一个完整学期的业务数据。这套测试数据既用来功能验证，也是答辩演示时的底气来源。
6.1 用真实业务验证规则逻辑
造数据时要有意识覆盖边界情况：有的学生学分已满，申报超上限项目必须被拦截；有的活动已结束但学生仍尝试报名；有的申报被驳回后学生重新提交；有的学生转专业了，学号不变但学院变了。每一种情况都对应一个业务校验分支，提前拿数据跑一遍，能发现大量"正常流程没问题、异常流程直接崩"的隐患。
6.2 后续可以扩展的方向
如果这个项目要接着做下去，我建议从三个方向扩展。一是对接学校统一身份认证，学生不用单独注册，直接用学号和统一密码登录；二是增加学分预警功能，每学期定期扫描学分不足的学生，自动发送提醒消息给辅导员；三是引入证明材料在线预览，学生上传PDF和图片，审核人直接在线查看，不用下载再打开。
我对这个项目的整体评价是：它覆盖了一个真实业务系统的所有关键环节——多角色权限、状态流转、事务一致性、防并发超卖、数据统计分析、文件导入导出，难度适中又有充足的发挥空间。把Spring Boot的核心特性通过它完整走了一遍之后，再去理解微服务、分布式这些更复杂的概念，地基会稳得多。
如果正在做类似的毕业设计，我给你最实在的一条建议：先花时间把业务流程图和数据字典画清楚再写代码。这个项目我前期画业务流程图和数据关系花了将近一周，后面写代码反而非常顺，几乎没有推翻重来的情况。业务不清就直接建表，才是真正的灾难。
