简介基于SpringBoot的学生请假管理系统论文聚焦高校学生请假场景针对传统纸质审批流程繁琐、耗时且易出错的问题完整阐述了以Java、SpringBoot、Vue和MYSQL为核心构建线上请假平台的背景、分析与实现过程。全文覆盖开发背景与意义、主要技术介绍、可行性分析、系统分析、功能模块设计、数据库设计、系统测试与优化等章节重点剖析个人中心、班级管理、基础数据管理、辅导员管理、公告管理、老师管理、留言管理七大模块并结合测试结果说明了系统的稳定性与高效性能直观帮助读者理解前后端分离架构及数据流转逻辑。资源仅1个docx文件压缩包约3.05MB内含中英文摘要、关键词、目录及完整论文正文框架适合计算机及相关专业学生作为毕业设计参考也可用于SpringBootVue全栈项目学习或毕业论文写作范本。目前已有180人学习浏览定位明确是一份结构完整、内容详实且可直接复用的学习资料。 又是一年毕业设计季后台经常有人问同一个选题基于SpringBoot的学生请假管理系统。说它眼熟是因为几乎每个学校都有人选说它难写是因为很多人做着做着发现它并不只是“增删改查”还有审批流转、权限隔离、状态管理这些东西要处理。这篇内容我就把这个项目从需求拆解、数据库设计、后端实现到论文写作的完整链路复盘一遍也会把平时最容易踩的坑挑出来说给正在做毕设或者打算用SpringBoot练手的人一个可以照抄的作业。1. 学生请假管理系统不是简单CRUD先搞懂真实业务再动手1.1 请假流程里的三种角色和四个状态节点很多第一次做这个系统的人上来就建表写接口结果写到审批环节就卡住了。根本原因是没有先想清楚请假业务到底是怎么跑的。你先把自己代入一个真实场景学生因为生病需要请假两天他打开系统提交请假申请填上请假类型病假、开始时间、结束时间、事由可能再上传一张医院证明。这时候请假单的状态是“待辅导员审批”辅导员登录能看到所有待审批的申请同意后如果学院还有规定需要系主任审核状态就变成“待系主任审批”如果不需要就直接变成“已通过”。学生看到审批通过后正常休假返回学校时再销假状态变成“已销假”。如果中途辅导员觉得理由不充分可以直接驳回状态变成“已驳回”学生可以修改后重新提交也可以撤销申请。这就是最典型的请假主流程。梳理下来角色至少有三类学生、审批人、系统管理员。审批人可以细分辅导员、班主任、院系负责人很多系统还要求两级审批。对应到系统里权限必须隔离学生只能提交申请和查看自己的记录审批人只能看到当前节点属于自己的申请管理员负责维护学生信息、班级信息、请假类型和基础数据统计。别小看这个权限划分它决定你后续接口设计是散成一团还是井井有条。1.2 SpringBoot不是唯一选择但它是最稳的选择技术选型上SpringBoot是目前做这类管理系统最稳妥的方案。原因很实际首先它内嵌Tomcat不用单独配置服务器mvn spring-boot:run一条命令就能把项目拉起来对毕设阶段足够友好。其次生态太成熟了要数据库操作有MyBatis-Plus和Spring Data JPA要权限控制有Spring Security和Shiro要接口文档有Swagger几乎你能想到的坑网上都有人踩过并留下了解决方案。用SpringBoot的时候有个版本细节要提前说清楚Spring Boot 2.x用的是javax命名空间Spring Boot 3.x以及后续版本改用jakarta命名空间。如果你在网上随便复制一段代码很可能因为版本差异报“包不存在”。就这个选题而言我个人建议用Spring Boot 2.7系列稳定、教程多、和大部分插件兼容等把项目做完想升级再升级没必要在毕业设计阶段跟版本较劲。除此之外Java版本也一样2.7通常配合JDK 8或11完全够用千万不要为了追求新特性去用JDK 17以上版本然后被各种兼容问题折磨。1.3 Flowable到底要不要上论文亮点和实现成本之间的权衡有一个搜索热词我一直很关注springboot使用flowable。很多人把Flowable工作流引擎当作这个项目的加分项。Flowable确实能做非常漂亮的BPMN流程图还支持可视化审批流转、会签、或签、驳回、撤回这些高级功能。问题是学生请假流程本身就是一条很固定的直线链路用Flowable相当于杀鸡用了牛刀。你要额外维护流程定义、部署BPMN文件、理解流程实例和任务节点的概念学习成本一下子就上去了。我的建议是分情况处理。如果你是做普通本科毕设目标是系统能跑、论文能过、答辩能讲清楚那就老老实实用状态机字段维护审批流转简单直接也容易自圆其说。如果你想要一个亮点可以把Flowable作为“扩展方案”写进论文的总结与展望部分说明“后续可以考虑引入工作流引擎以支持更灵活的审批场景”这样既体面又不用真的掉进工作流引擎的大坑。当然如果你已经对Flowable很熟那集成上来肯定加分但大多数人没有必要在毕设阶段为了一个固定流程去硬啃一套引擎。2. 数据库设计决定系统上限六张核心表和一张审批记录表2.1 用户、角色、班级基础数据表别贪多数据库是这类系统最容易出问题的地方也是论文里必须写清楚的部分。基础数据这部分我建议用经典的RBAC模型不要图省事把“角色”字段直接写进用户表。虽然写死角色确实简单但后面如果班主任和辅导员是同一个人、或者同一个用户同时承担两种角色你就傻眼了。所以宁可多一张关联表也要保持用户和角色的多对多关系。基础表大概长这样CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50) NOT NULL, class_id BIGINT, phone VARCHAR(20), email VARCHAR(100), status TINYINT DEFAULT 1, create_time DATETIME, update_time DATETIME ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(30) NOT NULL UNIQUE, role_name VARCHAR(50) NOT NULL ); CREATE TABLE sys_user_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, role_id BIGINT NOT NULL ); CREATE TABLE sys_class ( id BIGINT PRIMARY KEY AUTO_INCREMENT, class_name VARCHAR(100) NOT NULL, grade VARCHAR(20), major VARCHAR(100), counselor_id BIGINT );如果学校要求有“班级”和“辅导员”的对应关系在sys_class里存一个counselor_id指向用户表这样查询某个辅导员名下的学生列表时直接关联班级表就行。这里有一个容易被忽略的问题一个辅导员通常带多个班级而一个班级只有一个辅导员所以把counselor_id放在班级表是合理的符合一对多关系。如果你反过来在用户表里存class_id那就需要保证同一个学生只能属于一个班级这样也没问题只是角色多的场景会更绕。2.2 请假单表与审批记录表主表加流水表模式请假业务的核心是请假单表和审批记录表。请假单表我命名为leave_info每一行就是一条完整的请假申请审批记录表命名为leave_approval每一行就是某条请假单在某一个审批节点上的一步操作记录。为什么要单独拆一张审批记录表因为一个申请可能被多次审批、多次驳回如果把审批意见直接写在请假单表里字段会无限膨胀而且无法还原完整的审批链路。拆出来之后每个节点是谁审的、审了没、意见是什么一目了然。CREATE TABLE leave_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, leave_type VARCHAR(20) NOT NULL COMMENT 事假/病假/公假, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, leave_days DECIMAL(5,1) NOT NULL, reason TEXT, attachment_url VARCHAR(255), status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1待审 2通过 3驳回 4已撤销 5已销假, current_approver_id BIGINT COMMENT 当前待审批人, create_time DATETIME, update_time DATETIME ); CREATE TABLE leave_approval ( id BIGINT PRIMARY KEY AUTO_INCREMENT, leave_id BIGINT NOT NULL, approver_id BIGINT NOT NULL, step TINYINT NOT NULL COMMENT 审批节点顺序, approve_result TINYINT NOT NULL COMMENT 1通过 2驳回, approve_comment VARCHAR(500), approve_time DATETIME );这里又要说一个关键点status字段和current_approver_id字段要配合使用。status管的是整张请假单处于什么阶段current_approver_id管的是这个阶段应该由谁来处理。当学生提交申请时status1current_approver_id该生班级对应的辅导员辅导员通过后如果系统配置了二级审批就更新current_approver_id为院系负责人status继续为1如果没有二级审批就直接把status改成2。驳回时status改成3。这样的设计写代码时很直观画E-R图和数据流图也顺。2.3 请假时长计算看似简单的逻辑最容易翻车请假时长是这类系统的隐藏考点。很多人直接用“结束时间减开始时间”得到毫秒数再除以86400000得到天数这在小学生眼里都合理但一旦涉及请假半天、跨天请假、周末请假结果就会很尴尬。我给一个务实的方案如果系统接受“以天为单位”请假那请假的起止时间建议用DATE类型而不是DATETIME比如“2024-05-20至2024-05-22”那请假天数就是22减20加1等于3天纯天然逻辑不需要处理小时分钟。可现实是很多学校允许“半天假”。我的做法是把天数拆成“全天”和“半天”的组合在提交表单时给两个日期选择和一个“上午/下午”选项后端按日历计算工作日的上午或下午数量。比如周一上午请假那就算0.5天。如果再要处理法定节假日就需要维护一张工作日历表属于加分项。论文里不要求你解决所有极端情况但你必须把计算规则说清楚说得越严谨答辩老师越没话说。这里再强调一遍leave_days字段用DECIMAL(5,1)不要用INT因为你确定会碰到0.5天。3. 接口、权限、流转核心代码这样写才算能跑3.1 接口规划一张表说清前后端契约后端开发的第一步不是写代码是定接口。我习惯先把所有接口列成一张表放在笔记里后续写Controller、写前端页面以及论文里画模块图都会轻松不少。请假系统最核心的接口就这些接口方法功能角色/api/auth/loginPOST登录获取token所有/api/leave/submitPOST提交请假申请学生/api/leave/myGET查看我的请假记录学生/api/leave/pendingGET查看待审批列表审批人/api/leave/approvePOST审批通过/驳回审批人/api/leave/revokePOST撤销申请学生/api/leave/finishPOST销假学生/api/leave/detailGET查看请假详情及审批记录学生/审批人/api/leave/exportGET导出请假记录Excel管理员/api/leave/statisticsGET统计各类型请假数据管理员前后端对接时有个常见问题日期时间到底传字符串还是传时间戳。我建议接口统一用符合JSON标准的字符串格式例如2024-05-20 08:30:00后端用LocalDateTime接收并且加JsonFormat注解指定格式JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private LocalDateTime startTime;这个注解缺失的后果你会在联调时体会得淋漓尽致——前端传到后端的日期少8小时或者直接报解析异常这类问题非常消耗时间提前定好格式能省一半力气。3.2 权限控制用自定义注解加拦截器就够了说到权限有的同学一听就慌觉得不用Spring Security就不算安全。实际上对这个项目来说最简单可靠的方式是“登录后签发token接口校验角色”。手动实现一个基于拦截器的权限控制核心就两步第一步登录成功后生成一个token把用户ID和角色信息放进去第二步写一个HandlerInterceptor在进入Controller之前解析token并判断当前接口要求的角色是否匹配。我习惯用一个自定义注解来声明接口的角色要求Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value(); }然后在Controller方法上加注解比如RequireRole({student}) PostMapping(/api/leave/submit) public Result submit(RequestBody LeaveSubmitDTO dto) { // 业务逻辑 }拦截器里通过反射拿到注解再和token中解析出的角色比对。这个方案的优点是代码量小、逻辑直白论文里能讲清楚每一行是干什么的缺点是如果系统再扩大比如引入细粒度权限、数据权限、动态菜单它就不够用了。但一个学生请假系统真的遇到这种需求的概率很低。当然如果你在论文里写“使用Spring Security实现身份认证与权限控制”那就踏踏实实用Spring Security不要只贴一个拦截器否则答辩的时候容易露馅。选你自己能讲明白的方案比选看起来高级的方案重要得多。3.3 多级审批状态机的正确打开方式多级审批的核心是状态流转。很多人写着写着就变成一堆if-else嵌套维护起来非常痛苦。我建议把状态流转做成一个简单的状态机先定义状态常量再写一个方法接收“当前状态”和“审批结果”返回“下一个状态”。比如public Integer nextStatus(Integer currentStatus, Integer approveResult) { if (currentStatus STATUS_PENDING approveResult 1) { return this.needSecondApprove() ? STATUS_PENDING : STATUS_APPROVED; } if (currentStatus STATUS_PENDING approveResult 2) { return STATUS_REJECTED; } return currentStatus; }这里有一个小的设计要害二级审批存在时status仍旧是“待审批”不能把它改成“已通过”否则后面的节点根本找不到这条待办。真正区别当前是第几级审批的是current_approver_id和审批记录表里的step字段。每次审批操作都要在同一个事务里完成两件事更新leave_info的status、current_approver_id同时插入一条leave_approval记录。这两步必须保证原子性千万别拆成两个接口或者不加Transactional不然会出现“审批记录写了但状态没变”这种灵异事件。提交请假申请时也需要做校验同一个学生不能同时存在两个“待审批”状态的请假单。这个可以写成一条SQL查询校验或者依赖数据库唯一索引。正常业务场景里学生确实不太可能同时请两次假但这个校验能挡住很多误操作也是论文测试用例里的一个亮点。3.4 前端方案不想写前端也有体面的办法前端是这个项目让很多人头疼的部分。这里给你三个方案按工作量从小到大排第一用Thymeleaf服务端渲染加Bootstrap写几个简单页面表单提交用传统的POST跳转这个方案最省事但页面体验比较原始适合只想快速跑通的场景。第二用Vue 3加Element Plus写一个独立的前端工程通过axios调后端接口这是目前最常见也最容易被接受的方案页面能做得比较完整论文截图也好看。第三直接基于若依等脚手架二次开发它能帮你把用户管理、角色管理、菜单管理都做好你只专注写请假业务就行但坏处是论文里很难解释清楚那些自动生成的代码答辩时容易心虚。如果让我给建议我会选第二个方案Vue加Element Plus。但如果你连Vue都不太熟有一个折中办法——先写纯HTML页面放在static目录下用jQuery和Bootstrap做交互后端只负责和这些页面联调。这个方案页面虽然朴素但结构足够清晰你把登录、申请表单、审批列表、统计页面做出来放在论文里一点不丢人。系统实现章节的重点永远是“这些页面能完成什么业务”而不是页面有多少炫酷特效。4. 从项目到论文把SpringBoot项目变成一篇合格毕设的全流程4.1 论文目录与每一章的写作重心项目做完只是第一步把项目变成论文是另一项硬功夫。你的目录结构要按学校要求来但绝大多数学校都遵循“绪论-技术介绍-需求分析-系统设计-系统实现-系统测试-总结”这条路。我建议的章节安排是第一章绪论写清楚为什么要做学生请假管理系统、现在学校请假还是线下跑腿盖章的痛点在哪里、国内外线上审批系统发展到什么程度。行文不要空喊口号比如“随着信息技术的发展”这种句子尽量少用直接写数字化、无纸化、审批效率这些具体问题。第二章相关技术介绍重点写SpringBoot、MyBatis-Plus、MySQL、JWT这些你真正用到的东西。每一节写清楚“是什么、有什么特点、为什么本项目选用它”。很多同学在这里三句话就写完了但至少写到一页把你用到的配置和机制讲透。只有你真正理解了答辩时才能接得住追问。第三、四、五章是核心。第三章需求分析写用例分析和功能清单第四章系统设计写总体架构、功能模块划分、数据库E-R图和表结构第五章系统实现按模块展示运行效果截图和关键代码片段。这一部分最重要的原则是代码和截图必须来自你自己的系统不要拿网上的Demo图充数老师一眼就能看出违和感。4.2 图表才是论文的骨架用例图、E-R图、时序图论文里最出效果的不是大段文字而是图表。我强烈建议在写论文之前在工具里把图先画好后面写文字其实就是照着图解释。常用的图有四种系统总体用例图学生、审批人、管理员三大角色各自的用例、请假流程图从提交到销假的状态流转、E-R图核心实体的字段和关系、关键时序图比如提交请假申请时前端、Controller、Service、Mapper之间的调用顺序。画图工具我推荐PlantUML因为它用代码描述图形改起来极快而且导出的图片足够清楚或者用draw.io免费且配置简单。注意一个细节图的风格要统一线条粗细、字体大小、颜色不要一张一个样。很多答辩老师翻到图就直接看规范度图好看了印象分就上去了。系统实现章节里代码不要贴长段尤其不要把几百行代码丢进去。每小节只贴最关键的方法比如审批状态流转方法、导出Excel的工具方法每段控制在二十到三十行内然后在代码下面用文字解释核心逻辑。全部代码可以放到附录或者提交到代码仓库里给老师一个链接这样既显得规范又不会让查重率爆炸。4.3 查重和格式过来人才知道的隐性要求查重是论文写作里最现实的一道坎。很多同学不知道论文查重查的是连续字符重复你从网上下载一段“系统基于B/S架构采用MVC分层设计……”这种通用句子基本句子一大段都会被标红。但这不是让你不写这些内容而是要学会用自己的话重新组织一遍。比如“本系统采用SpringBoot框架”这种陈述加上你的具体场景和理由就变成了“考虑到学生请假流程涉及多种角色和状态流转项目选用SpringBoot框架通过其自动配置能力快速搭建项目骨架并配合MyBatis-Plus降低数据访问层开发工作量”这样既有效表达含义又能和网上的模板拉开差距。格式方面各个学校的毕设模板五花八门但有一个共性要求图表要编号、要有标题、引用要规范。参考文献尽量选期刊和书籍不要只挂几篇博客链接。答辩之前一定要把图表的“编号-标题”检查一遍跳号是高频扣分点有些老师专门查这个。最后目录自动生成不要手打页码不然修改之后页码错乱会非常狼狈。5. 我在这类系统里踩过的坑以及后续优化方向5.1 时间格式化、时区、跨天请假时间类Bug三连时间问题是这类系统的高发问题我自己的项目里也踩过。第一坑是JSON时间解析失败前端传过来的日期字符串报错。这个可以用全局Jackson配置解决把ObjectMapper的日期格式统一设置好再配合JsonFormat兜底。第二坑是Java的LocalDateTime和MySQL的DATETIME之间有时区问题数据库连接串里一定要加上serverTimezoneAsia/Shanghai否则可能出现差8小时的诡异现象处理起来非常费劲。第三坑是跨天请假计算错误比如学生说“我周五下午到周一上午请假”你要算工作日的半天数如果按自然日算会把周末也算了。我的简化处理是先捞出一张配置好的工作日历表只计算每个工作日上午或下午的数量。如果你不想做这么复杂那就把需求文档改成“按自然天计算”并说明本系统不支持半天假这也是一种合理的设计只要和论文保持一致就行。5.2 并发审批下状态被覆盖加版本号还是加锁另一个容易翻车的是并发审批。想象一下辅导员的电脑上同时开着两个浏览器标签页都打开了同一条待审批记录第一个页面点了“通过”第二个页面紧接着点了“通过”。如果代码只是先查出状态再更新状态第二个请求会用“已通过”的旧状态覆盖掉前一次审批结果导致审批记录表里出现两条同一节点的记录。解决方式有两种一是给leave_info表加version字段在更新时带上“update时校验version”的条件二是在更新SQL里直接带上当前状态条件比如执行“UPDATE leave_info SET status 1 WHERE id ? AND status 0”如果更新行数为0就说明状态已被别人修改直接返回“操作失败请刷新后重试”。我更推荐第二种因为不用引入额外字段语义也更清楚。这个坑虽然平时不容易触发但你把它写进系统测试章节说明你考虑了并发一致性反而会成为论文的加分项。5.3 统计报表SQL的性能细节管理员端通常会有一个统计页面按月展示请假人数、按类型展示请假占比。如果学生数据量不大直接写普通SQL没问题但要注意几个细节。按月汇总可以用DATE_FORMAT函数SELECT DATE_FORMAT(start_time, %Y-%m) AS month, leave_type, COUNT(*) AS count FROM leave_info WHERE status 2 GROUP BY month, leave_type ORDER BY month DESC;如果系统后续数据量变大给leave_info表的start_time和status加上联合索引否则查询会走全表扫描。导出Excel功能建议用EasyExcel生成真正的.xlsx文件不要用POI手写大量样板代码EasyExcel封装好之后只要一行命令就能写数据到列表对毕设来说效率提升非常明显。这里也提醒一下量大的数据不要直接在浏览器端一次性返回全部记录导出接口做成异步下载会好很多但这不是必须的你在论文里能说明“数据量超过一定规模后的优化方案”就足够体现思考深度了。5.4 后续可以怎么升级工作流、消息通知、移动端最后聊聊这个系统的扩展方向这部分可以直接写进论文的“总结与展望”。真正的生产环境里请假审批往往还会和课表冲突校验结合学生请病假需要上传病历照片并归档审批通过之后自动发送通知给任课老师和宿管这些都是很实际的需求。技术上可以做的事也很多把固定审批流程改造成Flowable工作流让不同学院可以自定义审批节点接入钉钉或企业微信机器人审批人没处理时自动提醒前端打包成小程序或者移动端H5让学生在手机上操作体验会好很多。我见过不少拿到优秀成绩的答辩项目功能并不复杂但都会在论证完现有系统后把“未来可扩展的方向”讲得让人信服。应届生不需要真的把扩展功能全做完但你要能说清楚“如果要做我大概会怎么做”这比堆功能更能体现工程素养。做这个系统的过程基本等于把Java Web开发的核心流程完整走了一遍业务建模、数据库设计、权限控制、状态流转、报表统计、论文撰写。如果你能独立把它做完并且能回答清楚“为什么这样设计、如果遇到问题怎么排查”这类问题那它带给你的收获绝对不只是一篇论文那么简单。最后给个小建议开发时记得把关键决策记录下来比如为什么用拦截器而不是Spring Security、为什么拆审批记录表这些记录在写论文和准备答辩时会变成你最宝贵的素材。祝你这套系统顺利跑通论文一遍过。本文还有配套的精品资源点击获取 SpringBoot学生请假管理系统：从CRUD到审批流转的完整毕设指南
简介基于SpringBoot的学生请假管理系统论文聚焦高校学生请假场景针对传统纸质审批流程繁琐、耗时且易出错的问题完整阐述了以Java、SpringBoot、Vue和MYSQL为核心构建线上请假平台的背景、分析与实现过程。全文覆盖开发背景与意义、主要技术介绍、可行性分析、系统分析、功能模块设计、数据库设计、系统测试与优化等章节重点剖析个人中心、班级管理、基础数据管理、辅导员管理、公告管理、老师管理、留言管理七大模块并结合测试结果说明了系统的稳定性与高效性能直观帮助读者理解前后端分离架构及数据流转逻辑。资源仅1个docx文件压缩包约3.05MB内含中英文摘要、关键词、目录及完整论文正文框架适合计算机及相关专业学生作为毕业设计参考也可用于SpringBootVue全栈项目学习或毕业论文写作范本。目前已有180人学习浏览定位明确是一份结构完整、内容详实且可直接复用的学习资料。 又是一年毕业设计季后台经常有人问同一个选题基于SpringBoot的学生请假管理系统。说它眼熟是因为几乎每个学校都有人选说它难写是因为很多人做着做着发现它并不只是“增删改查”还有审批流转、权限隔离、状态管理这些东西要处理。这篇内容我就把这个项目从需求拆解、数据库设计、后端实现到论文写作的完整链路复盘一遍也会把平时最容易踩的坑挑出来说给正在做毕设或者打算用SpringBoot练手的人一个可以照抄的作业。1. 学生请假管理系统不是简单CRUD先搞懂真实业务再动手1.1 请假流程里的三种角色和四个状态节点很多第一次做这个系统的人上来就建表写接口结果写到审批环节就卡住了。根本原因是没有先想清楚请假业务到底是怎么跑的。你先把自己代入一个真实场景学生因为生病需要请假两天他打开系统提交请假申请填上请假类型病假、开始时间、结束时间、事由可能再上传一张医院证明。这时候请假单的状态是“待辅导员审批”辅导员登录能看到所有待审批的申请同意后如果学院还有规定需要系主任审核状态就变成“待系主任审批”如果不需要就直接变成“已通过”。学生看到审批通过后正常休假返回学校时再销假状态变成“已销假”。如果中途辅导员觉得理由不充分可以直接驳回状态变成“已驳回”学生可以修改后重新提交也可以撤销申请。这就是最典型的请假主流程。梳理下来角色至少有三类学生、审批人、系统管理员。审批人可以细分辅导员、班主任、院系负责人很多系统还要求两级审批。对应到系统里权限必须隔离学生只能提交申请和查看自己的记录审批人只能看到当前节点属于自己的申请管理员负责维护学生信息、班级信息、请假类型和基础数据统计。别小看这个权限划分它决定你后续接口设计是散成一团还是井井有条。1.2 SpringBoot不是唯一选择但它是最稳的选择技术选型上SpringBoot是目前做这类管理系统最稳妥的方案。原因很实际首先它内嵌Tomcat不用单独配置服务器mvn spring-boot:run一条命令就能把项目拉起来对毕设阶段足够友好。其次生态太成熟了要数据库操作有MyBatis-Plus和Spring Data JPA要权限控制有Spring Security和Shiro要接口文档有Swagger几乎你能想到的坑网上都有人踩过并留下了解决方案。用SpringBoot的时候有个版本细节要提前说清楚Spring Boot 2.x用的是javax命名空间Spring Boot 3.x以及后续版本改用jakarta命名空间。如果你在网上随便复制一段代码很可能因为版本差异报“包不存在”。就这个选题而言我个人建议用Spring Boot 2.7系列稳定、教程多、和大部分插件兼容等把项目做完想升级再升级没必要在毕业设计阶段跟版本较劲。除此之外Java版本也一样2.7通常配合JDK 8或11完全够用千万不要为了追求新特性去用JDK 17以上版本然后被各种兼容问题折磨。1.3 Flowable到底要不要上论文亮点和实现成本之间的权衡有一个搜索热词我一直很关注springboot使用flowable。很多人把Flowable工作流引擎当作这个项目的加分项。Flowable确实能做非常漂亮的BPMN流程图还支持可视化审批流转、会签、或签、驳回、撤回这些高级功能。问题是学生请假流程本身就是一条很固定的直线链路用Flowable相当于杀鸡用了牛刀。你要额外维护流程定义、部署BPMN文件、理解流程实例和任务节点的概念学习成本一下子就上去了。我的建议是分情况处理。如果你是做普通本科毕设目标是系统能跑、论文能过、答辩能讲清楚那就老老实实用状态机字段维护审批流转简单直接也容易自圆其说。如果你想要一个亮点可以把Flowable作为“扩展方案”写进论文的总结与展望部分说明“后续可以考虑引入工作流引擎以支持更灵活的审批场景”这样既体面又不用真的掉进工作流引擎的大坑。当然如果你已经对Flowable很熟那集成上来肯定加分但大多数人没有必要在毕设阶段为了一个固定流程去硬啃一套引擎。2. 数据库设计决定系统上限六张核心表和一张审批记录表2.1 用户、角色、班级基础数据表别贪多数据库是这类系统最容易出问题的地方也是论文里必须写清楚的部分。基础数据这部分我建议用经典的RBAC模型不要图省事把“角色”字段直接写进用户表。虽然写死角色确实简单但后面如果班主任和辅导员是同一个人、或者同一个用户同时承担两种角色你就傻眼了。所以宁可多一张关联表也要保持用户和角色的多对多关系。基础表大概长这样CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50) NOT NULL, class_id BIGINT, phone VARCHAR(20), email VARCHAR(100), status TINYINT DEFAULT 1, create_time DATETIME, update_time DATETIME ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(30) NOT NULL UNIQUE, role_name VARCHAR(50) NOT NULL ); CREATE TABLE sys_user_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, role_id BIGINT NOT NULL ); CREATE TABLE sys_class ( id BIGINT PRIMARY KEY AUTO_INCREMENT, class_name VARCHAR(100) NOT NULL, grade VARCHAR(20), major VARCHAR(100), counselor_id BIGINT );如果学校要求有“班级”和“辅导员”的对应关系在sys_class里存一个counselor_id指向用户表这样查询某个辅导员名下的学生列表时直接关联班级表就行。这里有一个容易被忽略的问题一个辅导员通常带多个班级而一个班级只有一个辅导员所以把counselor_id放在班级表是合理的符合一对多关系。如果你反过来在用户表里存class_id那就需要保证同一个学生只能属于一个班级这样也没问题只是角色多的场景会更绕。2.2 请假单表与审批记录表主表加流水表模式请假业务的核心是请假单表和审批记录表。请假单表我命名为leave_info每一行就是一条完整的请假申请审批记录表命名为leave_approval每一行就是某条请假单在某一个审批节点上的一步操作记录。为什么要单独拆一张审批记录表因为一个申请可能被多次审批、多次驳回如果把审批意见直接写在请假单表里字段会无限膨胀而且无法还原完整的审批链路。拆出来之后每个节点是谁审的、审了没、意见是什么一目了然。CREATE TABLE leave_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, leave_type VARCHAR(20) NOT NULL COMMENT 事假/病假/公假, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, leave_days DECIMAL(5,1) NOT NULL, reason TEXT, attachment_url VARCHAR(255), status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1待审 2通过 3驳回 4已撤销 5已销假, current_approver_id BIGINT COMMENT 当前待审批人, create_time DATETIME, update_time DATETIME ); CREATE TABLE leave_approval ( id BIGINT PRIMARY KEY AUTO_INCREMENT, leave_id BIGINT NOT NULL, approver_id BIGINT NOT NULL, step TINYINT NOT NULL COMMENT 审批节点顺序, approve_result TINYINT NOT NULL COMMENT 1通过 2驳回, approve_comment VARCHAR(500), approve_time DATETIME );这里又要说一个关键点status字段和current_approver_id字段要配合使用。status管的是整张请假单处于什么阶段current_approver_id管的是这个阶段应该由谁来处理。当学生提交申请时status1current_approver_id该生班级对应的辅导员辅导员通过后如果系统配置了二级审批就更新current_approver_id为院系负责人status继续为1如果没有二级审批就直接把status改成2。驳回时status改成3。这样的设计写代码时很直观画E-R图和数据流图也顺。2.3 请假时长计算看似简单的逻辑最容易翻车请假时长是这类系统的隐藏考点。很多人直接用“结束时间减开始时间”得到毫秒数再除以86400000得到天数这在小学生眼里都合理但一旦涉及请假半天、跨天请假、周末请假结果就会很尴尬。我给一个务实的方案如果系统接受“以天为单位”请假那请假的起止时间建议用DATE类型而不是DATETIME比如“2024-05-20至2024-05-22”那请假天数就是22减20加1等于3天纯天然逻辑不需要处理小时分钟。可现实是很多学校允许“半天假”。我的做法是把天数拆成“全天”和“半天”的组合在提交表单时给两个日期选择和一个“上午/下午”选项后端按日历计算工作日的上午或下午数量。比如周一上午请假那就算0.5天。如果再要处理法定节假日就需要维护一张工作日历表属于加分项。论文里不要求你解决所有极端情况但你必须把计算规则说清楚说得越严谨答辩老师越没话说。这里再强调一遍leave_days字段用DECIMAL(5,1)不要用INT因为你确定会碰到0.5天。3. 接口、权限、流转核心代码这样写才算能跑3.1 接口规划一张表说清前后端契约后端开发的第一步不是写代码是定接口。我习惯先把所有接口列成一张表放在笔记里后续写Controller、写前端页面以及论文里画模块图都会轻松不少。请假系统最核心的接口就这些接口方法功能角色/api/auth/loginPOST登录获取token所有/api/leave/submitPOST提交请假申请学生/api/leave/myGET查看我的请假记录学生/api/leave/pendingGET查看待审批列表审批人/api/leave/approvePOST审批通过/驳回审批人/api/leave/revokePOST撤销申请学生/api/leave/finishPOST销假学生/api/leave/detailGET查看请假详情及审批记录学生/审批人/api/leave/exportGET导出请假记录Excel管理员/api/leave/statisticsGET统计各类型请假数据管理员前后端对接时有个常见问题日期时间到底传字符串还是传时间戳。我建议接口统一用符合JSON标准的字符串格式例如2024-05-20 08:30:00后端用LocalDateTime接收并且加JsonFormat注解指定格式JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private LocalDateTime startTime;这个注解缺失的后果你会在联调时体会得淋漓尽致——前端传到后端的日期少8小时或者直接报解析异常这类问题非常消耗时间提前定好格式能省一半力气。3.2 权限控制用自定义注解加拦截器就够了说到权限有的同学一听就慌觉得不用Spring Security就不算安全。实际上对这个项目来说最简单可靠的方式是“登录后签发token接口校验角色”。手动实现一个基于拦截器的权限控制核心就两步第一步登录成功后生成一个token把用户ID和角色信息放进去第二步写一个HandlerInterceptor在进入Controller之前解析token并判断当前接口要求的角色是否匹配。我习惯用一个自定义注解来声明接口的角色要求Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value(); }然后在Controller方法上加注解比如RequireRole({student}) PostMapping(/api/leave/submit) public Result submit(RequestBody LeaveSubmitDTO dto) { // 业务逻辑 }拦截器里通过反射拿到注解再和token中解析出的角色比对。这个方案的优点是代码量小、逻辑直白论文里能讲清楚每一行是干什么的缺点是如果系统再扩大比如引入细粒度权限、数据权限、动态菜单它就不够用了。但一个学生请假系统真的遇到这种需求的概率很低。当然如果你在论文里写“使用Spring Security实现身份认证与权限控制”那就踏踏实实用Spring Security不要只贴一个拦截器否则答辩的时候容易露馅。选你自己能讲明白的方案比选看起来高级的方案重要得多。3.3 多级审批状态机的正确打开方式多级审批的核心是状态流转。很多人写着写着就变成一堆if-else嵌套维护起来非常痛苦。我建议把状态流转做成一个简单的状态机先定义状态常量再写一个方法接收“当前状态”和“审批结果”返回“下一个状态”。比如public Integer nextStatus(Integer currentStatus, Integer approveResult) { if (currentStatus STATUS_PENDING approveResult 1) { return this.needSecondApprove() ? STATUS_PENDING : STATUS_APPROVED; } if (currentStatus STATUS_PENDING approveResult 2) { return STATUS_REJECTED; } return currentStatus; }这里有一个小的设计要害二级审批存在时status仍旧是“待审批”不能把它改成“已通过”否则后面的节点根本找不到这条待办。真正区别当前是第几级审批的是current_approver_id和审批记录表里的step字段。每次审批操作都要在同一个事务里完成两件事更新leave_info的status、current_approver_id同时插入一条leave_approval记录。这两步必须保证原子性千万别拆成两个接口或者不加Transactional不然会出现“审批记录写了但状态没变”这种灵异事件。提交请假申请时也需要做校验同一个学生不能同时存在两个“待审批”状态的请假单。这个可以写成一条SQL查询校验或者依赖数据库唯一索引。正常业务场景里学生确实不太可能同时请两次假但这个校验能挡住很多误操作也是论文测试用例里的一个亮点。3.4 前端方案不想写前端也有体面的办法前端是这个项目让很多人头疼的部分。这里给你三个方案按工作量从小到大排第一用Thymeleaf服务端渲染加Bootstrap写几个简单页面表单提交用传统的POST跳转这个方案最省事但页面体验比较原始适合只想快速跑通的场景。第二用Vue 3加Element Plus写一个独立的前端工程通过axios调后端接口这是目前最常见也最容易被接受的方案页面能做得比较完整论文截图也好看。第三直接基于若依等脚手架二次开发它能帮你把用户管理、角色管理、菜单管理都做好你只专注写请假业务就行但坏处是论文里很难解释清楚那些自动生成的代码答辩时容易心虚。如果让我给建议我会选第二个方案Vue加Element Plus。但如果你连Vue都不太熟有一个折中办法——先写纯HTML页面放在static目录下用jQuery和Bootstrap做交互后端只负责和这些页面联调。这个方案页面虽然朴素但结构足够清晰你把登录、申请表单、审批列表、统计页面做出来放在论文里一点不丢人。系统实现章节的重点永远是“这些页面能完成什么业务”而不是页面有多少炫酷特效。4. 从项目到论文把SpringBoot项目变成一篇合格毕设的全流程4.1 论文目录与每一章的写作重心项目做完只是第一步把项目变成论文是另一项硬功夫。你的目录结构要按学校要求来但绝大多数学校都遵循“绪论-技术介绍-需求分析-系统设计-系统实现-系统测试-总结”这条路。我建议的章节安排是第一章绪论写清楚为什么要做学生请假管理系统、现在学校请假还是线下跑腿盖章的痛点在哪里、国内外线上审批系统发展到什么程度。行文不要空喊口号比如“随着信息技术的发展”这种句子尽量少用直接写数字化、无纸化、审批效率这些具体问题。第二章相关技术介绍重点写SpringBoot、MyBatis-Plus、MySQL、JWT这些你真正用到的东西。每一节写清楚“是什么、有什么特点、为什么本项目选用它”。很多同学在这里三句话就写完了但至少写到一页把你用到的配置和机制讲透。只有你真正理解了答辩时才能接得住追问。第三、四、五章是核心。第三章需求分析写用例分析和功能清单第四章系统设计写总体架构、功能模块划分、数据库E-R图和表结构第五章系统实现按模块展示运行效果截图和关键代码片段。这一部分最重要的原则是代码和截图必须来自你自己的系统不要拿网上的Demo图充数老师一眼就能看出违和感。4.2 图表才是论文的骨架用例图、E-R图、时序图论文里最出效果的不是大段文字而是图表。我强烈建议在写论文之前在工具里把图先画好后面写文字其实就是照着图解释。常用的图有四种系统总体用例图学生、审批人、管理员三大角色各自的用例、请假流程图从提交到销假的状态流转、E-R图核心实体的字段和关系、关键时序图比如提交请假申请时前端、Controller、Service、Mapper之间的调用顺序。画图工具我推荐PlantUML因为它用代码描述图形改起来极快而且导出的图片足够清楚或者用draw.io免费且配置简单。注意一个细节图的风格要统一线条粗细、字体大小、颜色不要一张一个样。很多答辩老师翻到图就直接看规范度图好看了印象分就上去了。系统实现章节里代码不要贴长段尤其不要把几百行代码丢进去。每小节只贴最关键的方法比如审批状态流转方法、导出Excel的工具方法每段控制在二十到三十行内然后在代码下面用文字解释核心逻辑。全部代码可以放到附录或者提交到代码仓库里给老师一个链接这样既显得规范又不会让查重率爆炸。4.3 查重和格式过来人才知道的隐性要求查重是论文写作里最现实的一道坎。很多同学不知道论文查重查的是连续字符重复你从网上下载一段“系统基于B/S架构采用MVC分层设计……”这种通用句子基本句子一大段都会被标红。但这不是让你不写这些内容而是要学会用自己的话重新组织一遍。比如“本系统采用SpringBoot框架”这种陈述加上你的具体场景和理由就变成了“考虑到学生请假流程涉及多种角色和状态流转项目选用SpringBoot框架通过其自动配置能力快速搭建项目骨架并配合MyBatis-Plus降低数据访问层开发工作量”这样既有效表达含义又能和网上的模板拉开差距。格式方面各个学校的毕设模板五花八门但有一个共性要求图表要编号、要有标题、引用要规范。参考文献尽量选期刊和书籍不要只挂几篇博客链接。答辩之前一定要把图表的“编号-标题”检查一遍跳号是高频扣分点有些老师专门查这个。最后目录自动生成不要手打页码不然修改之后页码错乱会非常狼狈。5. 我在这类系统里踩过的坑以及后续优化方向5.1 时间格式化、时区、跨天请假时间类Bug三连时间问题是这类系统的高发问题我自己的项目里也踩过。第一坑是JSON时间解析失败前端传过来的日期字符串报错。这个可以用全局Jackson配置解决把ObjectMapper的日期格式统一设置好再配合JsonFormat兜底。第二坑是Java的LocalDateTime和MySQL的DATETIME之间有时区问题数据库连接串里一定要加上serverTimezoneAsia/Shanghai否则可能出现差8小时的诡异现象处理起来非常费劲。第三坑是跨天请假计算错误比如学生说“我周五下午到周一上午请假”你要算工作日的半天数如果按自然日算会把周末也算了。我的简化处理是先捞出一张配置好的工作日历表只计算每个工作日上午或下午的数量。如果你不想做这么复杂那就把需求文档改成“按自然天计算”并说明本系统不支持半天假这也是一种合理的设计只要和论文保持一致就行。5.2 并发审批下状态被覆盖加版本号还是加锁另一个容易翻车的是并发审批。想象一下辅导员的电脑上同时开着两个浏览器标签页都打开了同一条待审批记录第一个页面点了“通过”第二个页面紧接着点了“通过”。如果代码只是先查出状态再更新状态第二个请求会用“已通过”的旧状态覆盖掉前一次审批结果导致审批记录表里出现两条同一节点的记录。解决方式有两种一是给leave_info表加version字段在更新时带上“update时校验version”的条件二是在更新SQL里直接带上当前状态条件比如执行“UPDATE leave_info SET status 1 WHERE id ? AND status 0”如果更新行数为0就说明状态已被别人修改直接返回“操作失败请刷新后重试”。我更推荐第二种因为不用引入额外字段语义也更清楚。这个坑虽然平时不容易触发但你把它写进系统测试章节说明你考虑了并发一致性反而会成为论文的加分项。5.3 统计报表SQL的性能细节管理员端通常会有一个统计页面按月展示请假人数、按类型展示请假占比。如果学生数据量不大直接写普通SQL没问题但要注意几个细节。按月汇总可以用DATE_FORMAT函数SELECT DATE_FORMAT(start_time, %Y-%m) AS month, leave_type, COUNT(*) AS count FROM leave_info WHERE status 2 GROUP BY month, leave_type ORDER BY month DESC;如果系统后续数据量变大给leave_info表的start_time和status加上联合索引否则查询会走全表扫描。导出Excel功能建议用EasyExcel生成真正的.xlsx文件不要用POI手写大量样板代码EasyExcel封装好之后只要一行命令就能写数据到列表对毕设来说效率提升非常明显。这里也提醒一下量大的数据不要直接在浏览器端一次性返回全部记录导出接口做成异步下载会好很多但这不是必须的你在论文里能说明“数据量超过一定规模后的优化方案”就足够体现思考深度了。5.4 后续可以怎么升级工作流、消息通知、移动端最后聊聊这个系统的扩展方向这部分可以直接写进论文的“总结与展望”。真正的生产环境里请假审批往往还会和课表冲突校验结合学生请病假需要上传病历照片并归档审批通过之后自动发送通知给任课老师和宿管这些都是很实际的需求。技术上可以做的事也很多把固定审批流程改造成Flowable工作流让不同学院可以自定义审批节点接入钉钉或企业微信机器人审批人没处理时自动提醒前端打包成小程序或者移动端H5让学生在手机上操作体验会好很多。我见过不少拿到优秀成绩的答辩项目功能并不复杂但都会在论证完现有系统后把“未来可扩展的方向”讲得让人信服。应届生不需要真的把扩展功能全做完但你要能说清楚“如果要做我大概会怎么做”这比堆功能更能体现工程素养。做这个系统的过程基本等于把Java Web开发的核心流程完整走了一遍业务建模、数据库设计、权限控制、状态流转、报表统计、论文撰写。如果你能独立把它做完并且能回答清楚“为什么这样设计、如果遇到问题怎么排查”这类问题那它带给你的收获绝对不只是一篇论文那么简单。最后给个小建议开发时记得把关键决策记录下来比如为什么用拦截器而不是Spring Security、为什么拆审批记录表这些记录在写论文和准备答辩时会变成你最宝贵的素材。祝你这套系统顺利跑通论文一遍过。本文还有配套的精品资源点击获取