Spring Boot学生请假系统源码拆解：权限管理与审批流实战

做Java后端这几年，GitHub上翻过的项目、毕业设计里被用烂的题目、面试时被问烂的业务场景，学生请假系统绝对算得上一个经典中的经典。只要涉及Spring Boot，几乎每个Java学习者都会拿这类管理系统练手，但真正能把请假这条业务链路讲明白、把代码写得能直接跑起来还带完整源码的，其实并不多。最近拿到一套编号17878的Spring Boot学生请假系统源码，从配置文件到数据库脚本、从前端页面到后端接口都相当完整，很适合正在做课设、毕设，或者刚学完Spring Boot想找一个真实项目来拆解的读者。

学生请假系统这个题目看着简单，实际上它把一个管理系统该有的东西都占全了：用户角色权限、业务审批流、状态流转、条件分页查询、文件处理、统计报表，样样都有。你把这套东西吃透，再去写什么审批系统、工单系统、报修系统，几乎都是换皮不换骨。这套源码基于Spring Boot框架搭建，采用经典单体架构，前端部分提供页面支持，后端接口规范清晰，数据库脚本和说明文档都齐全，属于那种拿到手就能照着跑、跑起来就能学、学完就能改的实用型项目。

1. 项目概览：学生请假系统的需求到底怎么拆

1.1 一个看似简单但五脏俱全的业务场景

学生请假系统表面上的需求就一句话：学生提交请假申请，老师审批，系统记录结果。但真把它落到代码层面，你会发现里面有非常多的细节需要处理。第一个问题是“角色”，学生、辅导员、院系管理员、系统管理员这四类人的操作权限完全不同，学生只能提交和查看自己的请假单，辅导员能审批自己管辖的学生，管理员则能看全校数据。第二个问题是“状态”，一张请假单不是简单通过或不通过，它还有待审批、已通过、已驳回、已销假、已撤销等中间态，每一次状态切换都要有对应的操作人、操作时间和操作记录。第三个问题是“约束”，比如请假时间不能重叠、请假天数超过一定天数需要更高层级审批、课程安排和请假日期要有逻辑校验，这些业务规则决定了代码的复杂程度。

对于学习者和做毕设的同学来说，这个项目最有价值的地方就在这里：它不是一个只会增删改查的玩具管理系统，而是涵盖了一条完整的业务链路。你从源码里能学到Controller、Service、Mapper三层之间是怎么协同的，能学到状态字段是怎么在数据库里落地、在后端里流转的，也能学到前端页面是怎么通过接口和后端交互的。这套源码17278也好、17878也好，关键不在编号，而在于它的业务闭环设计，这一点是很多所谓“管理系统源码”根本做不到的。

1.2 源码包里到底应该有什么

拿到源码之后第一步，不是急着去启动项目，而是先把目录结构看一遍。正常情况下，一套完整的Spring Boot学生请假系统源码应该包含：

• 后端Java代码目录（src/main/java），下面按controller、service、mapper、entity、config等分包分层。
• 资源配置目录（src/main/resources），里面有application.yml或application.properties配置文件、Mapper的XML文件、静态资源等。
• 前端页面目录，如果是前后端分离项目会有独立的Vue工程，如果是服务端渲染项目则放在templates和static目录下。
• 数据库脚本（一般是.sql文件），建库建表语句和初始化数据都在里面。
• 项目文档，至少应该有一份README说明，告诉你JDK版本、数据库版本、启动步骤、默认账号密码。

很多同学一拿到源码就直接点击启动类，结果报一堆错误，然后就开始怀疑人生。实际上绝大多数的跑不起来，问题都出在没看README、没导入数据库脚本、没修改数据库密码这几个地方。这套源码虽然不是商业项目，但基本的工程规范还是有的，你按照文档一步步来，十分钟内跑起来是没问题的。

1.3 核心功能模块拆分与边界划分

从业务角度拆分，一个完整的学生请假系统至少需要以下模块。用户管理模块解决登录和身份识别问题，包括账号密码校验、角色判断、基本信息维护。请假管理模块是核心，包含请假申请、条件分页查询、审批通过、审批驳回、销假登记、撤销申请等操作。审批记录模块负责流水账式的日志审计，每一步操作都记录在案。课程与时间管理模块处理教学周、节次、课程信息等基础数据，为请假时间校验提供依据。系统管理模块负责菜单管理、日志查看、数据备份等后台功能。

这五个模块的边界一定要清楚，否则代码写到最后就是一团乱麻。在源码里，模块边界通常体现为数据库表之间的外键关联、包名分包规则、Service之间的调用关系。你读源码的时候，建议先从数据库表结构入手，把核心表理清楚之后，再去看Controller层有哪些接口，每个接口对应什么业务操作。这种自上而下的读法，比从main方法开始一行一行看代码高效得多。

2. 技术选型：这套源码为什么选了Spring Boot

2.1 Spring Boot到底解决了什么问题

如果你用过早期的SSH框架或者SSM框架，一定体会过那种地狱级的配置体验：几十个XML配置文件、一堆jar包版本冲突、外部Tomcat部署、日志框架打架。Spring Boot最大的贡献，就是把这些繁琐的配置变成了约定俗成的自动配置。它内嵌了Tomcat，让你可以用一个main方法启动整个Web项目；它通过starter机制统一管理依赖版本，你只需要引入spring-boot-starter-web，一个Web项目的Web层依赖就齐了；它把数据库、Redis、消息队列等常见中间件的配置都抽象成了统一的自动配置类。

放到学生请假系统这个场景里，Spring Boot的优势更加明显。学生请假系统的核心功能无非是REST接口、数据库操作、模板页面渲染、文件上传下载、拦截器鉴权，而这些正好都是Spring Boot最擅长的领域。用Spring Boot来写这种管理系统，几乎不需要额外搭建环境，开发效率非常高。对于校内课设、毕业设计来说，Spring Boot自带的这些特性还能让你在答辩的时候有话可说，比如“通过Spring Boot的自动配置简化了项目搭建”“使用内嵌Servlet容器免去了外部部署的麻烦”，这些表述都是很标准的加分项。

2.2 配套组件怎么选：MyBatis-Plus、MySQL、前端框架

这套源码采用的是Spring Boot + MyBatis-Plus + MySQL的经典组合。MyBatis-Plus和原生MyBatis相比，最大的变化是内置了通用Mapper，简单的单表增删改查你甚至不用写一行SQL，直接调用ServiceImpl里的save、removeById、page等方法就能完成，这对学生项目来说开发效率提升非常明显。如果你接触过MyBatis-Plus的分页插件，一定知道那个PaginationInnerInterceptor，配置好之后只需要传入IPage对象，分页查询的limit语句、总记录数查询都会自动帮你处理好，比起手写复杂的分页SQL要省心太多。

前端部分，如果源码里带的是Vue + Element UI的前后端分离工程，那交互体验会更好一些，组件库齐全，表格、表单、弹窗这些管理系统的常规操作都有现成实现。如果源码里用的是模板引擎（Thymeleaf、JSP），那你直接在浏览器里输入地址就能看到页面渲染效果。两种方案各有适用场景，前后端分离适合展示现代Web开发技术栈，服务端渲染适合快速跑通项目。你拿到源码后先看清楚它属于哪一种，再去决定本地的启动方式。判断方法很简单，看pom.xml里有没有前端工程路径，看看有没有vue.config.js之类的文件，或者看启动时是否同时需要另外启动一个前端npm服务。

下面用表格对比一下学生请假系统常用的几组技术选型，方便你做二次开发时心里有数：

2.3 登录鉴权：JWT还是会是Spring Security

学生请假系统里一定要有登录鉴权，不然谁都能随便审批别人学生的请假单就乱套了。常见的做法有两种：一种是基于Session的登录态管理，登录成功后把用户信息存进Session，每次请求通过拦截器去Session里拿当前用户；另一种是基于JWT（JSON Web Token）的方案，登录成功后服务端签发一个带有用户信息和过期时间的Token，前端把Token放在请求头里，后端通过过滤器来解析Token，从而识别当前用户。

JWT方案的优点是无状态、适合前后端分离场景，缺点是Token一旦泄露没法主动失效，除非你额外维护一个黑名单。Session方案实现简单，学生项目里足够用，但在集群部署场景下就得考虑Session共享的问题。这套源码里采用的方式，你可以在Config包下面找到拦截器或过滤器配置来确认。不管是哪种方案，权限控制的核心思路是一样的：前端不显示没有权限的按钮，后端在接口层面做统一拦截，关键操作还要验证数据归属权（比如学生只能操作自己的请假单），不能只靠前端藏起来就算完。

3. 核心功能实现：请假从申请到审批的完整链路

3.1 登录鉴权与角色控制的前后端协作

登录这一块要处理的问题比看起来复杂多了。首先是密码存储，明文存库是绝对不行的，至少要使用MD5加盐或者BCrypt进行哈希处理。其次是Token或Session的有效期管理，正常来说学生登录一次能管半天，管理员可能希望过期时间更长，这就要在配置里设置。然后是角色控制，学生、辅导员、管理员看到的菜单和操作按钮都要能区分开。

在源码里，这部分的实现一般分成三层。第一层是认证过滤，拦截器或过滤器对所有接口请求进行Token解析，解析不到或者过期就返回401状态码。第二层是角色权限校验，通过自定义注解（比如@RequireRole("admin")）或者硬编码在业务逻辑里判断当前用户角色。第三层是前端路由和按钮权限控制，后端接口返回的登录用户信息中包含角色标识，前端根据角色动态渲染菜单。这套体系不复杂，但却是整个项目的安全底线，我在实际开发中就踩过坑，曾经只依赖前端隐藏按钮，后端接口没有做权限判断，被人绕过页面直接调接口就把数据改了，这是非常要命的教训。

3.2 请假单的状态流转设计

请假单的状态是整个系统的核心数据之一。一个好的状态设计，应该让后面每一次操作都清晰可控。通常我会建议在数据库中用一个int字段来存状态，比如0表示待审批、1表示已通过、2表示已驳回、3表示已销假、4表示已撤销，再加一个varchar字段存状态描述方便调试。项目里也见过用枚举类直接映射的，但数据库里存字符串会占用更多空间，查询和统计都不如int字段来得简洁。

这张请假单在其生命周期里会经历这么几次状态变更：学生提交申请，生成状态为待审批的记录；辅导员审核通过，状态变成已通过；学生假期结束回来销假，状态变成已销假；如果辅导员驳回了，状态变成已驳回；学生撤销申请，状态变成已撤销。每次状态变更都会往审批记录表里插入一条流水，记录操作人、操作类型（提交、通过、驳回、销假）、操作时间、备注说明。这里有一个容易被忽略的点：状态更新必须加条件判断，比如更新语句里带上 where status = 当前期望的状态，防止两个人同时在操作同一张请假单，把状态给改乱了。

下面是一段典型的状态更新伪代码思路，真实的Mapper实现大同小异：

java复制// Service层状态更新逻辑
public boolean approve(Long leaveId, Long approverId, String remark) {
    LeaveApplication leave = leaveMapper.selectById(leaveId);
    // 前置校验：仅待审批状态可以审批
    if (leave == null || leave.getStatus() != LeaveStatusEnum.PENDING.getCode()) {
        throw new BusinessException("当前状态不可审批");
    }
    // 执行状态更新，同时插入审批流水
    leaveMapper.updateStatus(leaveId, LeaveStatusEnum.APPROVED.getCode());
    approvalRecordMapper.insert(...);
    return true;
}

这里核心的要点是那个“前置校验”。它不只是判断这单有没有被审批过，更重要的是它天然地处理了一部分并发问题，跑在前面的请求先把状态改掉了，后面那个请求发现状态已经不对，就直接抛异常了，不会再重复审批。这种利用数据库状态字段做乐观锁校验的思路，在很多业务系统里都是通用的优化方案。

3.3 多级审批与延期审批的扩展设计

很多学生请假系统还有一个隐藏需求，就是请假天数不同，审批的层级也不同。比如三天以内的假辅导员直接审批就行，超过三天的假需要院系负责人二次审批。这套源码里如果你仔细看，会发现审批链的逻辑有分支判断。读源码时重点关注审批策略类或审批判断接口，它会根据请假天数决定审批人角色的选择顺序。

延期请假更是一个容易遗漏的功能点。学生请三天假，结果第四天还没回来，这就要走延期申请。正常的做法不是把原假单状态改掉，而是基于原假单生成一张新的关联单。这里面涉及到“父单子单”的概念，要在请假表里加一个parent_id字段，用于指向原始请假单。看源码的时候如果看到这样的设计，说明作者对业务的理解是到位的。给你一个判断源码质量的小技巧：不要只看增删改查写得顺不顺，要去看看有没有处理这些非常规业务场景，这才是项目有没有价值的关键。

3.4 分页查询与统计报表的实现细节

请假系统的首页和列表页最考验“查询”功力。第一是条件的动态拼装，你不可能为了每一种查询条件组合都写一条SQL，MyBatis-Plus的LambdaQueryWrapper这时候就非常好用，它可以按条件动态拼接查询项。第二是分页查询，MyBatis-Plus的Page对象可以接收当前页码和每页条数，底层会自动生成limit语句返回总记录数。

第三是统计报表，比如按请假类型统计各年级的请假天数，按周统计某门课程的请假人数。这些统计分析SQL通常要用group by和join之类的语法，放在Mapper的XML里写会比Java代码里拼接更清晰。看源码的时候，可以把这部分单独拿出来研究一下，学习一下怎么写聚合SQL，这对后面做扩展功能（比如导出Excel报表）很有帮助。如果你要给系统加导出功能，别忘了Spring Boot里的EasyExcel或者POI工具都可以快速实现数据导出，学生项目里用EasyExcel会更轻量。

4. 数据库设计：请假系统的表结构怎么设计才不踩坑

4.1 核心数据表与角色关系

数据库设计的好坏决定了项目能支撑的业务复杂度，也决定了后面改需求的痛苦程度。学生请假系统关联的表通常包括：用户表（包含学生和教师/辅导员，只是角色字段不同）、学生信息表（扩展学号、班级、年级等）、请假申请表（核心业务表）、审批记录表（流程日志）、课程表（教学班、节次），还有系统管理相关的菜单表和操作日志表。

这里有一个学生项目里常见的误区：把学生和老师放在完全不同的两张表里。这样设计的问题是辅导员和老师本质上都属于教职工，强行拆表会带来无数的关联查询麻烦。推荐的做法是一张sys_user表存账号密码和角色标识，一张teacher表存教师工号院系，一张student表存学生学习院系班级，通过用户ID进行关联。至于系统管理员，可以直接在sys_user里加一条记录，专门有管理员角色类型，不用单独建表。

4.2 请假申请表与审批记录表的关键字段

请假申请表（leave_application）是整个系统的核心主表，字段设计建议如下。主键id直接使用自增主键就行。user_id是学生用户ID，用于关联用户表。start_time和end_time的字段类型建议用datetime，存精确到秒，方便后续做时间冲突的比对。leave_type存放请假类型，比如病假、事假、公假、其他，一般用int状态码映射字典。reason是请假原因，建议用varchar(500)，别用text，text字段在列表查询时不方便处理也没必要。status存放当前状态。create_time、update_time分别记录创建时间和更新时间。create_by、update_by存操作人ID，这样审计信息就齐全了。

审批记录表（approval_record）的设计重点是流水不可改。字段包括id、leave_id关联请假单、approver_id审批人ID、action_type操作类型（提交、同意、驳回、销假）、remark处理意见、create_time操作时间。增加一个status_before和status_after也是不错的设计，这样每一次操作前后的状态一目了然，想要回滚或者排查问题都很方便。

有一点要特别提醒：请假时间冲突检测。如果项目里没有做这个校验，那么学生完全可以同一时间段提交两条不同的假单，这显然是业务漏洞。冲突检测的核心SQL大概是：

sql复制SELECT COUNT(*) FROM leave_application
WHERE user_id = #{userId}
  AND status IN (0, 1, 3)
  AND start_time < #{endTime}
  AND end_time > #{startTime}

如果查出来的count大于0，就说明这段时间已经存在请假记录，直接拒绝本次申请。很多项目没有意识到这个点，但你在做毕设答辩的时候能主动提出解决了这个问题，面试官和老师对你的评价会高不少。

4.3 索引设计建议

设计索引时最需要考虑的是那些高频的查询条件。对请假表来说，user_id要建索引，因为学生查自己的请假单是最频繁的操作。status也要考虑建索引，因为列表页经常按状态过滤。start_time和end_time可以建联合索引，用于时间范围查询。如果有按审批人查询的需要，审批记录表的leave_id和approver_id也要建索引。

索引不是越多越好，每张表每多一个索引，插入更新时就要多维护一份B+树结构，会影响写入性能。对学生系统这种数据量比较小的场景，三到五个实用索引完全够了。记住一个原则：索引要建在真正高频的查询条件列上，不要脑子一热哪个字段都加索引。

5. 关键代码走读：Controller、Service、Mapper三层怎么分工

5.1 Controller层：只管参数接收和结果返回

很多学生写的项目，Controller层代码恨不得把所有的查询逻辑和业务判断全塞进去，类动辄几百行，这种做法后面维护起来非常痛苦。规范的写法是Controller层做三件事：接收前端请求参数、调用Service层方法、把处理结果封装成统一返回对象返回给前端。参数校验可以通过注解来做，常见的@NotNull、@NotBlank、@Min、@Max、@Email等都能完成基本校验。更复杂的业务校验，比如时间是否冲突、状态是否合法，这些都放到Service层里面做。

统一返回体也是一个值得关注的设计。源码里一般会有一个R类或者Result类来统一接口返回格式，字段通常包括code（状态码）、message（提示信息）、data（具体业务数据）。前端只要根据code做判断就能知道请求是成功还是失败，不用每个接口单独约定。全局异常处理通常配合@RestControllerAdvice使用，对业务异常和系统异常分别处理，生成类CodeMsg的统一返回体。这样就算代码里抛了异常，前端拿到的也是结构化的JSON数据，而不是一个堆栈式的错误页面。

5.2 Service层：业务规则和事务处理的主战场

Service层是业务的真正核心，这里的代码决定了整个系统的业务逻辑是否正确。事务处理是Service层一个特别关键的关注点，像请假申请这种操作，往请假表插入一条记录的同时也要插入一条初始的审批记录，两个操作必须是一个原子操作。为了让它们保持同步，类的对应方法上要加@Transactional注解。需要注意的是，处理事务时不能直接把异常吞掉，要抛出RuntimeException子类，否则事务会失效。

Service层还需要处理好角色边界。学生能操作的数据只能是自己创建的申请，辅导员只能审批自己管辖的学生，管理员可以查看所有数据但不能直接修改学生信息（这个权限可以另行设计）。这些归属校验放在Service层最合适，因为它是业务规则的最终防线。很多黑接口攻击就是直接绕过前端权限按钮来调用API的，如果归属校验做得不好，攻击一投一个准。

5.3 Mapper层：SQL语句优化与XML映射

Mapper层的写法直接决定了数据库操作的效率和代码的整洁度。MyBatis-Plus的BaseMapper给了你基础的单表CRUD方法，但涉及多表关联查询和复杂统计时还是需要写XML。XML文件里写SQL要注意参数传递的方式，针对@Param注解传参，尽量避免使用Map传参，因为Map模式对于参数的含义并不明确，后面维护很痛苦。

分页查询的常见配置我在这里也顺手记录一下。MyBatis-Plus的分页只需要两步：配置类里注册PaginationInnerInterceptor，查询时传入Page对象。

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

接着在Service层调用page方法时传入当前页码和每页条数，查询结果就自动带上了total、pages等分页信息，非常方便。

5.4 配置文件与多环境切换

学生请假系统这种应用，开发的时候连本地数据库，部署的时候要连服务器数据库，如果每次切换环境都要改配置文件的话，纯属给自己添麻烦。Spring Boot的原生多环境配置解决的就是这个问题。在application.yml里用spring.profiles.active=dev指定当前环境，再分别用application-dev.yml、application-prod.yml维护不同环境的数据源配置、日志级别等。启动时用命令参数指定环境，比如java -jar leave-system.jar --spring.profiles.active=prod就能直接切到生产配置。

配置这一块的坑主要集中在日期时间格式和时区上。MySQL连接的URL里建议加上serverTimezone=Asia/Shanghai，否则经常会出现时间差8个小时的问题。JSON序列化时也要注意LocalDateTime的格式，默认序列化出来的是一串数组，看着极其难受，需要在Jackson配置里指定date-format格式。如果前端显示的时间是“2025-01-05 18:30:00”，那就要保证后端返回的字符串格式保持一致，否则前端解析会很麻烦。

6. 源码运行、二次开发与常见问题排查

6.1 环境准备与启动步骤

如果你之前没跑过Spring Boot项目，建议先确认这些环境是否已正确安装：JDK 1.8或以上版本，Maven 3.6及以上，MySQL 5.7及以上，还有IDEA或Eclipse任选其一。不建议直接用刚出的高版本JDK，有时候版本太高反而会出现一些兼容性问题，学习阶段用JDK8最稳妥。

拿到源码后的完整启动流程是这样的：

1. 用IDEA打开源码目录，等待Maven自动下载依赖。
2. 在MySQL中新建数据库（比如leave_system），把sql目录下的数据库脚本导进去，这一步会同时建好表和初始化数据。
3. 打开application.yml，把数据库的地址、用户名、密码改成你自己的。
4. 找到启动类，直接运行main方法。
5. 打开浏览器输入http://localhost:8080，登录管理员账号检查功能是否正常。

如果项目是前后端分离的，那还要多一步前端启动：在vue-admin目录下执行npm install安装依赖，然后npm run serve启动前端开发服务器，通过前端提供的地址访问系统。这类项目的前后端通讯通常通过代理转发到后端的8080端口，前端devServer的proxy配置在vue.config.js里，第一次跑的时候要重点看一下这个代理路径是否和后端接口前缀一致。

6.2 常见问题速查表

跑Spring Boot项目，最常见的坑就那么几个，我把它们整理成一张速查表，遇到问题直接对照排查：

我在实际带项目时发现，刚接触的同学最容易卡在“数据库表没导进去”这步。有个笨办法很管用：用Navicat打开数据库，看有没有对应的表名，如果一个表都没有，那一定是sql脚本没执行成功。顺序是从管理端数据开始执行，先有用户表才能有后续的申请审批表，否则外键关联会报错。

6.3 源码阅读顺序与二次开发建议

源码拿到了，看代码也要讲究顺序，不然容易看得一头雾水。我建议按照“数据库 → 实体类 → Mapper接口 → Service实现 → Controller接口 → 前端调用”的顺序来读。先从表结构理解业务模型，然后看实体类如何映射表字段，再看Mapper封装了哪些查询方法，接着在Service里追业务逻辑的流转过程，最后通过Controller确认每个接口的入参出参。前端那边主要以看懂页面调用了哪些接口为主，不必逐行读。

如果你想在这套系统上做一些扩展功能，这里给几个容易上手且有亮点的方向：增加一个课程请假统计Excel导出功能，利用EasyExcel把某门课程的请假名单导出成表格；增加一个未销假自动提醒功能，通过Spring Boot的Schedule定时任务扫描已经过了假期结束时间但还没销假的记录，给辅导员发送站内提醒；把原有的Session登录方式改造成JWT，虽然改造量不小，但学到的知识很值。这些功能都很适合作为课程设计或答辩的加分项。

最后再分享一个我个人的体会。这种管理系统源码，真正值钱的不是你把它跑起来那一步（那只是第一步），而是你能不能讲清楚每个表为什么这么建、每个状态为什么这么流转、每个权限为什么这么控制。学生请假系统虽然小，但它的业务设计思想是通用型管理系统都能套用的。把这份源码吃透了，你看待其他Spring Boot项目的眼光会完全不同。