每年到了评奖评优和毕业资格审核的时候各高校的第二课堂学分核算都是一场人肉大战。学生拿着各种活动证明、证书复印件找辅导员签字辅导员对着纸质表格逐个核对学院教务再汇总成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 统一返回结果和异常处理前后端分离项目最怕接口返回格式不统一前端拿到数据还得猜。我定义了一个ResultT类统一包含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的核心特性通过它完整走了一遍之后再去理解微服务、分布式这些更复杂的概念地基会稳得多。如果正在做类似的毕业设计我给你最实在的一条建议先花时间把业务流程图和数据字典画清楚再写代码。这个项目我前期画业务流程图和数据关系花了将近一周后面写代码反而非常顺几乎没有推翻重来的情况。业务不清就直接建表才是真正的灾难。 基于Spring Boot的第二课堂学分管理系统设计与实现
每年到了评奖评优和毕业资格审核的时候各高校的第二课堂学分核算都是一场人肉大战。学生拿着各种活动证明、证书复印件找辅导员签字辅导员对着纸质表格逐个核对学院教务再汇总成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 统一返回结果和异常处理前后端分离项目最怕接口返回格式不统一前端拿到数据还得猜。我定义了一个ResultT类统一包含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的核心特性通过它完整走了一遍之后再去理解微服务、分布式这些更复杂的概念地基会稳得多。如果正在做类似的毕业设计我给你最实在的一条建议先花时间把业务流程图和数据字典画清楚再写代码。这个项目我前期画业务流程图和数据关系花了将近一周后面写代码反而非常顺几乎没有推翻重来的情况。业务不清就直接建表才是真正的灾难。