毕业设计实战：基于Spring Boot+MySQL的疫情期间高校人员管理系统，从需求分析到测试的避坑全指南！

小飞计算机毕设
35 阅读15分钟

毕业设计实战：基于Spring Boot+MySQL的疫情期间高校人员管理系统，从需求分析到测试的避坑全指南！

家人们谁懂啊！当初做疫情期间高校人员管理系统毕设时，光“教师打卡信息表”和“学生请假表”的审核状态逻辑就卡了一周——一开始没考虑多角色审核流程，教师提交的返校申请管理员和操作人员都能修改，数据权限直接乱套，导师看了直摇头说“权限设计有问题”😫 后来踩遍所有坑才总结出这套高效落地流程，今天把疫情特殊场景下的需求分析、技术选型、多角色功能实现到测试的核心细节说透，学弟学妹们不用再熬夜调权限，轻松搞定毕设！

一、先搞懂“疫情期间高校人员管理系统要啥”！需求分析别跑偏

刚开始我以为就是普通的人员管理系统，花两周加了“人脸识别打卡”，结果导师一句“核心是健康状态追踪、行程管理、返校审批，不是生物识别”直接打回重改！后来才明白，疫情系统需求分析得先抓准“特殊时期管理需求”，这步做对，少走80%弯路。

1. 核心用户&功能拆解（踩坑后总结版）

系统有四类核心用户：管理员、操作人员、教师、学生（别漏“操作人员”角色！我当初只设管理员和师生，结果所有日常审核都压给管理员，系统崩溃后才补了操作人员角色），功能必须按角色严格区分：

  • 管理员端（系统管理核心）：

    • 人员管理：管理操作人员账号（新增、重置密码）、审核教师/学生基本信息、逻辑删除离职人员
    • 资讯管理：发布疫情资讯（新增/编辑/删除）、设置资讯类型（通知/政策/提醒）、管理资讯图片
    • 审批监督：查看教师/学生返校申请记录、监督操作人员审核工作、导出全校健康统计报表
    • 系统监控：查看登录日志、监控异常操作、备份系统数据

  • 操作人员端（日常审核核心）：

    • 信息审核：审核教师/学生返校申请（同意/拒绝）、审批请假信息、确认居家隔离状态
    • 留言处理：查看并回复学生留言、分类处理咨询问题、标记已解决事项
    • 健康监测：查看全校打卡记录、筛选异常健康状态、跟踪风险地区人员
    • 数据维护：维护教师/学生基本信息、更新联系方式、修正错误数据

  • 教师端（健康上报核心）：

    • 健康打卡：每日上报健康状态（是否健康）、填写打卡地点、添加备注信息
    • 行程管理：提交居家信息（地点/是否隔离/风险等级）、更新同住人员状况
    • 申请服务：提交返校申请（预计时间/原因）、提交请假申请（起止时间/原因）
    • 信息查看：查看个人打卡历史、查询审批进度、浏览疫情资讯

  • 学生端（信息上报核心）：

    • 健康打卡：每日上报健康状态、填写当前位置、上传健康码截图（我当初漏了这功能，导师让补上）
    • 行程报备：提交居家信息（地点/隔离状态/风险等级）、更新家庭人员健康状况
    • 申请服务：提交返校申请、提交请假申请（支持事假/病假类型）
    • 互动服务：留言咨询问题、查看回复、查看个人所有申请记录

2. 疫情特殊需求分析（血泪教训！）

  • 别照搬普通系统！疫情系统核心是“健康追踪”和“行程管控”，我当初按普通考勤系统设计，漏了“风险等级”字段，导师问“怎么区分中高风险地区人员”时直接懵了
  • 一定要画多角色用例图！用DrawIO画“管理员-发布疫情资讯”“操作人员-审核返校申请”“教师-健康打卡”“学生-留言咨询”，四个角色功能清晰展示，汇报时导师一眼就看懂系统架构（当初只画了管理员和学生的，被说考虑不周全）
  • 写“疫情场景约束文档”！把特殊要求写清楚（如“隔离人员每日必须打卡”“返校申请需提前3天提交”“风险地区人员返校需特殊审批”），编码时对着做，不跑偏

3. 可行性分析要突出“疫情适用性”

导师必问“为什么疫情期间需要这个系统”，从3个角度写，显专业：

  • 技术可行性：Spring Boot + Vue + MySQL组合成熟稳定，疫情数据实时性要求高，Spring Boot的快速响应特性完全满足；Redis缓存健康状态数据，提高查询效率（别用MongoDB！我当初试了，疫情数据结构规整，用MySQL更合适）
  • 社会可行性：疫情常态化管理需要信息化工具，系统能减少人工统计错误，提高疫情响应速度，符合高校疫情防控要求
  • 操作可行性：界面参考“健康码”小程序，简化操作流程，教师学生10秒完成打卡，操作人员批量审核，管理员一键导出报表，上手快

二、技术选型要稳！这套组合经过疫情检验

刚开始我想炫技用Spring Cloud微服务+Elasticsearch，结果“全校健康数据统计”接口响应要8秒——微服务调用链太长😫 后来换成Java 8 + Spring Boot 2.7 + MySQL 8.0 + Vue 2 + Element UI + Redis，疫情数据高频访问场景下，响应速度提升3倍！

1. 技术栈核心选择（附疫情场景适配理由）

技术工具为什么选它疫情场景适配点避坑提醒！
Java 8稳定成熟，企业级应用验证疫情系统要求7×24小时稳定运行，Java 8长期支持版最可靠别用Java 17！部分疫情上报插件兼容性差
Spring Boot 2.7快速开发，内置健康检查端点可快速开发疫情打卡、返校审批等核心接口，健康检查便于监控系统状态配置文件中必须设server.shutdown=graceful，避免疫情数据提交时系统重启导致数据丢失
MySQL 8.0事务支持完善，数据一致性要求高疫情数据不容出错，MySQL的ACID特性保证打卡、审批等操作原子性必须开启binlog，便于疫情数据追溯和恢复
Vue 2 + Element UI组件丰富，开发效率高Element UI的表格、表单、弹窗组件适合疫情数据展示和填报别用Vue 3 + Element Plus！我当初试了，部分组件不稳定，疫情紧急时出问题难排查
Redis 6.x缓存热点数据，减轻数据库压力缓存全校今日健康状态、风险地区列表等高频访问数据配置持久化策略，避免服务器重启疫情缓存数据丢失
Nginx负载均衡，静态资源加速疫情资讯图片、健康码截图等静态资源快速加载配置gzip压缩，减少疫情页面加载时间

2. 疫情系统开发环境搭建（关键步骤）

  1. 疫情数据模拟准备：用Python脚本生成测试数据（1000个学生+200个教师的30天打卡记录、返校申请、请假记录），编码前先验证表结构是否合理
  2. Spring Boot项目初始化：用Spring Initializr创建项目，必须引入： 
    <!-- 疫情系统核心依赖 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId> <!-- 缓存健康状态 -->
</dependency>
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>easyexcel</artifactId> <!-- 疫情报表导出 -->
</dependency>
  3. 疫情专用配置：application.yml中配置： 
    pandemic:
  settings:
    daily-report-required: true  # 每日打卡必填
    return-school-advance-days: 3  # 返校提前申请天数
    risk-area-update-cron: "0 0 6 * * ?"  # 每天6点更新风险地区

三、数据库设计：疫情数据关联复杂，关系理清

这是疫情系统“最易出错点”，我当初“学生表”和“打卡表”没建索引，查“某班级今日未打卡学生”要15秒，被导师批评“不考虑性能”😫 后来按“疫情数据流”重新设计，查询优化到0.2秒。

1. 核心疫情实体&关联（附ER图技巧）

疫情系统核心是“人员健康轨迹”，8张核心表，关联必须清晰：

  • 人员基础表：学生表（xuesheng）、教师表（laoshi）、操作人员表（caozuorenyuan）
  • 疫情业务表：打卡信息表（daka）、居家信息表（jujia）、返校申请表（fanxiao）、请假表（qingjia）
  • 辅助表：留言板表（liuyanban）、疫情资讯表（zixun）

关键关联设计：

  1. 学生→打卡：一对多，一个学生每天可打卡一次（需加UNIQUE(xuesheng_id, insert_date)约束，避免重复打卡）
  2. 教师→返校申请：一对多，一个教师可提交多次返校申请（每次需操作人员审核）
  3. 操作人员→留言回复：一对多，一个操作人员可回复多条留言

ER图绘制要点：

  1. 用Visio或draw.io，实体用矩形，疫情专用字段用特殊颜色（如红色标健康状态字段）
  2. 关系线标注多重性（1:1、1:N、M:N）
  3. 必加备注：如“隔离人员打卡频率=每日2次”

2. 疫情数据表关键字段设计（易错点！）

-- 学生打卡表 - 疫情特殊字段
CREATE TABLE `xuesheng_daka` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `xuesheng_id` int(11) NOT NULL COMMENT '关联学生',
  `daka_name` varchar(200) DEFAULT NULL COMMENT '打卡地点（疫情要求精确定位）',
  `daka_content` text COMMENT '备注（症状描述等）',
  `jiankang_types` int(11) NOT NULL COMMENT '是否健康：1健康，2发热，3咳嗽（别用0/1，要细分）',
  `tiwen` decimal(3,1) DEFAULT NULL COMMENT '体温（疫情新增字段，我当初漏了）',
  `is_isolate` tinyint(1) DEFAULT '0' COMMENT '是否隔离中',
  `insert_time` date NOT NULL COMMENT '打卡日期（按日期分区，提高查询效率）',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_date` (`xuesheng_id`,`insert_time`), -- 防止重复打卡
  KEY `idx_health_date` (`jiankang_types`,`insert_time`) -- 按健康状态快速查询
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生打卡表-疫情核心表';

3. 疫情数据关联测试SQL（必做！）

建表后立即测试复杂疫情查询：

-- 查询“高风险地区且未打卡的学生”
SELECT s.xuesheng_name, s.xuesheng_phone, j.jujia_name, j.jujiafengxiandengji_types
FROM xuesheng s
LEFT JOIN xuesheng_jujia j ON s.id = j.xuesheng_id 
  AND j.insert_time = CURDATE()  -- 今日居家信息
LEFT JOIN xuesheng_daka d ON s.id = d.xuesheng_id 
  AND d.insert_time = CURDATE()  -- 今日打卡
WHERE j.jujiafengxiandengji_types = 3  -- 高风险地区
  AND d.id IS NULL  -- 未打卡
  AND s.xuesheng_delete = 0;

能正确查出数据说明关联正确，否则赶紧检查外键。

四、功能实现：疫情场景下的核心模块

不用做所有功能！先搞定4个核心疫情模块，答辩足够出彩：

1. 管理员端：疫情资讯管理模块（疫情特色！）

疫情资讯要实时更新，重点“资讯类型分类”和“发布时效控制”：

  • 操作逻辑：
    1. 发布资讯前校验：标题必填、类型必选（通知/政策/提醒）、发布时间≤当前时间
    2. 紧急资讯可置顶，普通资讯按时间倒序，疫情政策类资讯永久保存
    3. 资讯支持富文本编辑，可插入风险地区地图、防疫指南图片
  • 页面设计（Vue + Element UI）：
    • 资讯列表：卡片式布局，紧急资讯红色边框，显示标题、类型、发布时间、阅读数
    • 发布页面：标题输入框、类型选择器（通知/政策/提醒）、富文本编辑器、封面图上传、定时发布开关
    • 数据统计：资讯阅读量趋势图、类型分布饼图

2. 操作人员端：返校申请审核模块（疫情核心！）

这是疫情系统最复杂模块，我当初漏了“审核历史追溯”，导师问“谁拒绝了某个申请”时查不到记录：

  • 操作逻辑：
    1. 待审核列表按提交时间排序，高风险地区申请标红预警
    2. 审核时必填审核意见（同意/拒绝原因），系统自动记录审核人和时间
    3. 批量审核功能：勾选多个同类型申请一键通过（如“全部低风险地区申请”）
    4. 审核后自动通知申请人（站内信+邮件，我当初只做了站内信，导师让补邮件通知）
  • 页面设计：
    • 筛选区：申请人姓名、风险等级、申请时间范围、审核状态（待审/已审）
    • 申请详情弹窗：显示申请人基本信息、行程轨迹、健康打卡历史、同住人员状况
    • 审核操作区：同意/拒绝按钮、审核意见文本框、附件上传（如核酸报告）

3. 教师端：健康打卡模块（高频使用！）

教师每日必用，重点“极简操作”和“异常提醒”：

  • 操作逻辑：
    1. 进入页面自动定位（需用户授权），显示上次打卡记录供参考
    2. 健康状态选择后，如选“发热”或“咳嗽”，必须填写症状详情和体温
    3. 提交时校验：是否已打卡（防止重复）、必填项是否完整
    4. 异常状态自动触发预警，通知操作人员跟进
  • 页面设计（移动端优先）：
    • 打卡表单：大按钮选择健康状态（绿色健康/黄色异常/红色发热）、滑动输入体温、地理位置显示
    • 历史记录：日历视图，绿色圆点=已打卡，红色=异常打卡，点击查看详情
    • 疫情提醒：显示今日风险地区列表、最新防疫政策摘要

4. 学生端：留言咨询模块（沟通桥梁！）

疫情政策多变，学生常有疑问，重点“快速响应”：

  • 操作逻辑：
    1. 留言分类选择（返校政策/隔离要求/打卡问题），便于操作人员分类处理
    2. 支持上传图片附件（如健康码异常截图）
    3. 操作人员回复后，系统标记“已回复”并通知学生
    4. 常见问题自动推荐（基于留言内容匹配）
  • 页面设计：
    • 留言列表：我的留言（按状态分组）、常见问题（固定展示）
    • 留言表单：问题类型下拉框、问题描述文本框、图片上传组件、紧急程度选择
    • 对话界面：类似聊天框，左侧学生问题，右侧操作人员回复，显示回复时间 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述

五、疫情系统测试要更严格！

疫情数据不能出错，测试要覆盖所有异常场景：

1. 功能测试（疫情特殊场景）

测试场景操作步骤预期结果疫情重要性
高风险地区学生提交返校申请学生居家信息设为高风险→提交返校申请→操作人员审核申请列表中标红预警，操作人员需查看核酸报告等附加材料高风险地区必须严格审核
教师发热状态打卡教师打卡选择“发热”状态→体温填38.5→提交系统记录异常打卡，自动通知操作人员，生成待处理任务发热人员必须及时追踪
学生连续3天未打卡模拟学生3天未打卡→操作人员查看未打卡报表显示该学生姓名、联系方式，标记为“重点跟进”防止漏报瞒报
疫情资讯紧急发布管理员发布类型为“紧急通知”的资讯资讯列表置顶显示，所有用户登录时弹窗提醒重要政策及时传达

2. 压力测试（疫情数据爆发场景）

疫情可能突然严重，系统要能承受：

  • 并发打卡测试：模拟5000名学生同时打卡，响应时间<2秒
  • 大数据量查询：查询全校30天打卡记录（约15万条），加载时间<5秒
  • 报表导出压力：导出全校月度健康报表（含图片），文件生成时间<30秒

3. 兼容性测试（多终端覆盖）

疫情期间用户可能用各种设备：

  • 手机浏览器：Chrome、Safari、微信内置浏览器（重点测！很多学生用微信打卡）
  • 平板设备：iPad、安卓平板，测横竖屏适配
  • 老旧电脑：IE11（学校机房可能还有），用polyfill兼容

六、答辩准备：突出疫情应对特色

  1. 演示流程要有故事性：按“疫情突发→学校紧急通知→学生健康打卡→异常人员追踪→返校审核→数据报表”流程演示，体现系统完整应对链条
  2. 讲“疫情场景解决方案”：比如“传统手工统计易出错→系统自动汇总；政策传达不及时→资讯模块实时推送；返校审批慢→线上流程加速”，突出信息化优势
  3. 准备疫情相关问题：
    • Q：系统如何保证疫情数据真实？ A：多重校验（定位验证、时间戳防篡改）、操作留痕、异常数据人工复核
    • Q：突发疫情时系统能承受吗？ A：已做压力测试，支持5000并发；数据库读写分离方案已设计，可快速扩容

最后：疫情系统毕设通关要点

以上就是疫情期间高校人员管理系统的避坑全指南！疫情系统毕设要抓住“健康追踪”和“流程管控”两个核心，把打卡、居家、返校、请假四个主线功能做扎实，权限设计一定要细致（四角色权限分离），数据关联必须清晰。

需要疫情系统核心源码（带健康打卡、返校审批完整流程）、疫情测试数据集（模拟1000学生30天数据）、多角色权限设计文档的学弟学妹，评论区扣“疫情系统”，我私发你；卡在某个疫情场景（如风险地区判断、异常状态预警），也可以留言，看到必回！

点赞收藏，疫情系统毕设不迷茫～祝大家顺利毕业，健康平安！😷➡️😊

avatar
文章
阅读
粉丝