简介校园请假管理信息系统是一套面向学校场景的管理信息系统实践案例适合学习管理信息系统、软件工程的学生与开发者参考用于理解请假申请、教师审批、数据统计等流程如何通过信息化手段落地。压缩包共136个文件约3.26MB以C#源码cs、资源文件resources、resx、图片素材jpg、png、程序集dll、exe及配置文件config、manifest为主另含解决方案与项目文件可据此还原系统结构并做二次开发。已有1973人学习下载说明其作为教学与练手素材具有一定参考价值。资源涵盖用户界面、数据库管理、业务逻辑、多级审批、报表统计与安全隐私等模块读者可从中梳理需求分析、系统设计到编码实现的完整链路并针对功能不完善之处进行优化改进积累信息系统开发的实战经验。1. 校园请假管理信息系统从纸质假条到全流程闭环的一次重构每到学期中段辅导员桌上就会堆起一摞假条病假、事假、公假混在一起签字靠手写统计靠 Excel销假靠学生自觉。等到期末要做请假数据汇总才发现有的假条丢了、有的超期没销、有的根本没走审批就离校了。这套「校园请假管理信息系统」要解决的正是这个场景把请假申请、多级审批、销假核验、数据统计串成一条可追溯的链路让管理信息系统真正承担起流程管控的职责而不是把纸质表格原样搬到网页上。它适合正在做管理信息系统方向毕设或课程设计的学生也适合需要给内部流程做轻量数字化改造的从业者参考。下面按需求、设计、实现、避坑、验收的顺序把整套方案拆开讲清楚。2. 需求与角色建模先把请假的业务链路画明白2.1 四类角色与三条主流程请假这件事看起来简单真正落到系统里核心是把「谁发起、谁审批、谁核验、谁统计」四个问题回答清楚。我一般会把角色收敛成四类学生、辅导员或班主任、院系管理员、系统管理员。角色一多权限就会失控所以宁可先少设几个后续再按需拆分。三条主流程分别是申请流程学生提交 → 辅导员初审 → 院系终审超过一定天数自动升级审批层级、销假流程学生返校后在规定时限内提交销假 → 辅导员核验 → 状态闭环、统计流程按班级、时间段、请假类型聚合输出可导出的报表。这三条流程决定了后面所有的表结构和接口设计需求阶段如果没把「超期未销假怎么处理」「请假天数跨审批层级怎么升级」这两个边界问清楚后面改起来就是血泪经验。需求梳理时建议直接产出一张角色-权限矩阵把每个角色能看的菜单、能操作的按钮列全。这张表后面会直接变成权限拦截器的配置省掉大量返工。2.2 关键业务规则与状态机请假单的状态不能随便定义否则审批流会变成玄学。通常的做法是收敛成六个状态待初审、待终审、已通过、已驳回、待销假、已销假。状态之间的迁移必须由明确的动作触发比如「已通过」只能由终审通过触发「待销假」只能由系统在学生请假开始时间到达后自动置位。这里有个容易被忽略的点驳回之后是否允许修改重提。我的建议是允许但每次重提生成新的审批记录原记录保留形成可追溯的审批历史。这样既照顾了学生体验也满足了审计要求。状态机的迁移规则建议在需求文档里用表格固定下来开发时直接照着写枚举和校验避免出现「已驳回的单子还能被审批」这类脏数据。2.3 非功能性需求的底线管理信息系统的非功能需求往往被学生忽略但答辩时导师最爱问。并发量不用吹得很大一个院系几千人峰值集中在节假日前后按 200 并发设计足够。响应时间上列表查询控制在 1 秒内审批提交控制在 500 毫秒内。数据保留上请假记录至少保留三年销假凭证如病历照片要考虑存储成本通常的做法是压缩后存对象存储数据库只存路径。安全方面至少要做到登录态校验、接口级权限拦截、敏感操作留痕。这些不是加分项是及格线。需求阶段把这些写进文档后面验收才有依据。3. 总体架构与技术选型分层结构与模块职责划分3.1 前后端分离的三层结构整套系统采用前后端分离架构前端负责交互与表单校验后端负责业务规则与数据持久化中间通过 RESTful 接口通信。分层上分三层表现层页面与组件、业务层Service承载审批流与状态机、数据层DAO 与数据库。这样分的好处是审批规则集中在业务层前端只做展示换界面不影响流程。技术选型上后端用 Spring Boot MyBatis-Plus前端用 Vue 3 Element Plus数据库用 MySQL 8。这套组合在管理信息系统里属于成熟稳妥的选择资料多、踩坑少适合毕设周期。缓存用 Redis 存登录态和字典数据文件存储用本地磁盘或对象存储均可按学校实际条件定。下面是一个典型的项目结构示意帮助理解模块边界leave-system/ ├── leave-web/ # 前端工程页面、路由、接口封装 ├── leave-service/ # 后端主工程 │ ├── controller/ # 接口层只做参数校验与转发 │ ├── service/ # 业务层审批流与状态机在此 │ ├── mapper/ # 数据访问层 │ └── common/ # 统一返回、异常、权限拦截 └── leave-doc/ # 需求、设计、接口文档这个结构的关键在于 controller 不写业务逻辑所有状态判断都下沉到 service。很多同学图省事在 controller 里直接改状态结果审批规则散落各处后期加一个「超时自动驳回」就得改十几个地方这是典型的翻车点。3.2 核心数据表设计数据表是管理信息系统的骨架设计得好后面写代码是顺水推舟设计得差就是天天打补丁。核心表我一般设计五张用户表、角色权限表、请假单主表、审批记录表、销假记录表。请假单主表的关键字段包括单号、学生 ID、请假类型、开始时间、结束时间、请假天数、事由、当前状态、当前审批节点、创建时间。审批记录表单独存每次审批动作包含审批人、审批结果、审批意见、审批时间与主表一对多。这样设计的好处是审批历史完整可查主表只存当前快照查询效率高。CREATE TABLE leave_apply ( id BIGINT PRIMARY KEY AUTO_INCREMENT, apply_no VARCHAR(32) NOT NULL COMMENT 请假单号规则年月日序列, student_id BIGINT NOT NULL COMMENT 申请人, leave_type TINYINT NOT NULL COMMENT 1病假 2事假 3公假, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, days DECIMAL(4,1) NOT NULL COMMENT 请假天数支持半天, reason VARCHAR(500) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待初审 1待终审 2已通过 3已驳回 4待销假 5已销假, current_node TINYINT NOT NULL DEFAULT 1 COMMENT 当前审批节点, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_apply_no (apply_no), KEY idx_student_status (student_id, status) );字段说明里有两个设计点值得强调一是days用 DECIMAL 而不是 INT因为半天假是真实存在的需求用整数会逼着你在业务层做换算容易出错二是idx_student_status联合索引因为学生端最高频的查询就是「我的请假记录按状态筛选」这个索引能把列表查询压到毫秒级。审批记录表则按apply_id建索引保证审批历史回显不拖慢主流程。3.3 权限模型与接口分层权限采用 RBAC 模型用户关联角色角色关联菜单和操作权限。接口层面用拦截器统一校验注解标记所需权限避免在每个方法里手写 if 判断。前端路由也按权限动态生成学生登录看不到审批菜单从入口上减少误操作。接口按资源划分/api/leave负责请假单的增删改查/api/approval负责审批动作/api/statistics负责统计报表。审批接口单独拆出来是因为审批动作涉及状态迁移和并发控制和普通 CRUD 混在一起容易出问题。这个分层思路在答辩时讲出来能体现你对系统边界的思考。4. 核心模块实现审批流、销假核验与统计报表4.1 多级审批流的代码落地审批流是这套系统的核心也是最容易写乱的地方。我的做法是把「当前节点 动作」映射成状态迁移用一个 service 方法统一处理而不是在每个 controller 里各写一套。Service public class ApprovalService { Transactional(rollbackFor Exception.class) public void approve(Long applyId, Long approverId, boolean pass, String comment) { LeaveApply apply applyMapper.selectById(applyId); // 并发控制只有状态未被他人改变时才允许审批 if (apply.getStatus() ! 0 apply.getStatus() ! 1) { throw new BizException(该请假单当前状态不可审批); } int nextStatus; int nextNode; if (!pass) { nextStatus 3; // 驳回流程终止 nextNode apply.getCurrentNode(); } else if (apply.getCurrentNode() 1) { nextStatus 1; // 初审通过进入终审 nextNode 2; } else { nextStatus 2; // 终审通过 nextNode 2; } // 乐观锁更新防止两个辅导员同时点通过 int rows applyMapper.updateStatus(applyId, apply.getStatus(), nextStatus, nextNode); if (rows 0) { throw new BizException(审批冲突请刷新后重试); } approvalMapper.insert(buildRecord(applyId, approverId, pass, comment)); } }这段代码有三个关键设计。第一状态校验放在最前面非法状态直接拒绝避免脏数据。第二用乐观锁updateStatus带原状态条件解决并发审批问题两个辅导员同时操作时只有一个能成功另一个收到明确提示这比数据库行锁轻量也比不管并发靠谱。第三审批记录和状态更新在同一个事务里要么都成功要么都回滚保证审批历史不会丢。参数上pass用布尔而不是字符串减少前端传参歧义comment驳回时必填通过时选填这个校验放在 controller 层做。审批节点目前是两级如果学校要求三天以上请假加一级院系审批只需在currentNode分支里加一个判断扩展成本很低。4.2 销假核验与超时提醒销假环节是很多同类系统缺失的一环导致「请假有记录、返校无凭证」。实现上系统在学生请假结束时间到达后通过定时任务把状态从「已通过」置为「待销假」并推送提醒。学生提交销假后辅导员核验状态置为「已销假」流程闭环。定时任务用 Spring 的Scheduled即可每天凌晨跑一次扫描结束时间在昨天且状态为「已通过」的单子。这里要注意时区问题服务器时间统一用东八区避免出现「明明昨天结束却今天还没提醒」的玄学。超时未销假的可以设置一个宽限期比如三天超过后标记为异常并进入统计报表供辅导员跟进。销假凭证的上传要做类型和大小限制图片压缩后存储数据库只存路径。核验时辅导员能看到凭证缩略图点击放大这个交互细节在答辩演示时很加分。4.3 统计报表与数据导出统计模块的价值在于把散落的请假数据变成管理决策依据。核心指标包括按班级统计请假人次和天数、按类型统计病事假占比、按时间段统计请假高峰、超时未销假名单。实现上用 MyBatis 写聚合 SQL结果直接映射到 VO前端用表格和简单图表展示。SELECT c.class_name, COUNT(*) AS apply_count, SUM(l.days) AS total_days, SUM(CASE WHEN l.leave_type 1 THEN 1 ELSE 0 END) AS sick_count FROM leave_apply l JOIN student s ON s.id l.student_id JOIN class c ON c.id s.class_id WHERE l.create_time BETWEEN #{start} AND #{end} AND l.status IN (2, 4, 5) GROUP BY c.class_name ORDER BY total_days DESC;这条 SQL 只统计已通过及之后的单子驳回和待审的不计入避免数据虚高。导出功能用 EasyExcel 流式写出几千条数据不会撑爆内存。报表页面加时间范围和班级筛选默认展示本学期减少辅导员的操作成本。统计口径一定要在页面上写清楚比如「请假天数按自然日计算」否则不同人理解不一致数据对不上又要扯皮。5. 避坑与常见问题排查那些答辩前最容易翻车的地方5.1 状态流转缺少并发控制现象两个辅导员同时审批同一张单子结果出现两条审批记录状态却只变了一次或者状态被覆盖成错误值。原因先查后改的写法在并发下必然出问题查询和更新之间有时间窗口。解决更新语句带上原状态作为条件判断影响行数为 0 就抛冲突异常同时给审批记录表加唯一约束单号 审批节点从数据库层面兜底。5.2 请假天数计算口径不一致现象前端显示 3 天后端算出 2.5 天统计报表又是 3 天三方对不上。原因有的按小时算、有的按自然日算、有的排除周末各写各的。解决天数计算收敛到一个工具方法统一按「结束时间减开始时间向上取整到 0.5 天」的规则前端只展示不计算所有口径以服务端为准并在页面标注规则说明。5.3 权限只做前端不做后端现象学生通过改 URL 或直接调接口能看到别的班级的请假记录甚至能调审批接口。原因前端隐藏了菜单但后端接口没校验角色和数据归属。解决拦截器统一校验角色权限涉及数据归属的查询强制拼接当前用户条件审批接口校验审批人是否为该学生所属辅导员。这条是安全底线答辩时被问到必须答得上来。5.4 定时任务重复执行或漏执行现象销假提醒发了两遍或者某天没跑导致状态没更新。原因多实例部署时每个实例都跑定时任务或者任务异常后没有补偿机制。解决单实例部署时问题不大多实例要用分布式锁或只在一台机器上开任务任务内部做幂等按「状态 日期」判断是否已处理异常时记录日志并支持手动触发补偿。5.5 文件上传拖垮存储与性能现象病历照片原图几 MB几十人上传后磁盘告警列表页加载凭证缩略图卡顿。原因没做压缩和类型限制列表直接加载原图。解决上传时校验类型和大小比如限制 5MB 内服务端压缩到合理尺寸再存列表只返回缩略图路径原图按需加载。存储路径按日期分目录避免单目录文件过多。6. 验收与答辩用一条完整链路证明系统跑得通验收这套系统我一般不看页面有多少个而是走一条完整链路学生提交一张跨三天的病假单 → 辅导员初审通过 → 院系终审通过 → 状态变为已通过 → 模拟时间到达结束日 → 定时任务置为待销假 → 学生上传凭证销假 → 辅导员核验 → 状态变为已销假 → 统计报表出现这条记录。这条链路走通说明申请、审批、销假、统计四个环节都活了比演示十个孤立页面有说服力。答辩时建议准备一张验收对照表把需求文档里的每条规则对应到具体操作和预期结果现场按表演示。下面是一个简化的对照表示例验收项操作预期结果多级审批初审通过后查看状态变为待终审终审人收到待办并发审批两个账号同时点通过一个成功一个提示冲突超时销假修改结束时间后触发任务状态变为待销假并收到提醒权限隔离学生直接调审批接口返回无权限不产生数据统计口径提交半天假后查报表天数按 0.5 累计与详情一致演示时把浏览器开发者工具的网络面板打开让导师看到接口返回和状态码比口头说「做了权限」可信得多。遇到答不上来的问题不要硬编直接说「这块目前是按 XX 规则实现的如果要求 XX改动点在 service 的哪个方法」反而显得你清楚系统边界。血泪经验是答辩前一定要用全新账号、全新数据完整走一遍链路别用开发时留下的脏数据演示否则很容易在「已驳回的单子为什么还能销假」这种问题上翻车。从那以后我每次交付前都强制走一遍「清库 → 造数 → 全链路 → 截图存档」的流程把验收证据留好。希望这套结构能帮到你照着改改就能变成你自己的方案。本文还有配套的精品资源点击获取