毕业设计实战：基于Spring Boot+MySQL的校园疫情防控系统全流程指南毕业设计实战：基于Spring Boot

毕业设计实战：基于Spring Boot+MySQL的校园疫情防控系统全流程指南

在开发“校园疫情防控系统”的过程中，数据关联性验证曾是核心痛点——因未在“健康打卡表”与“请假申请表”间建立数据校验机制，导致学生请假期仍在校园打卡，耗费1天重构业务流程才解决🚨。基于此次实战经验，本文将系统拆解从需求分析、技术选型到测试验收的全流程要点，为筹备疫情防控类毕设的同学提供可落地的实施指南。

一、需求分析：精准定位防疫场景，避免功能偏离

部分同学在毕设初期容易陷入“功能堆砌”误区，试图开发完整OA系统。笔者曾花费三天开发“物资管理系统”，最终因偏离“学生健康监测、出入管理、信息发布”核心需求被导师要求删除。可见，明确“疫情场景-管理痛点”对应关系，是控制开发范围的关键。

1. 核心用户与功能拆解（优化后权限体系）

系统用户分为管理员、学生两类，前期曾因权限混淆，导致学生可查看他人核酸报告，明确数据隔离后系统隐私性显著提升。具体分工如下：

管理员端（核心必做功能）

学生管理：学生信息维护（支持按班级/学号筛选），批量导入学生数据，重置学生密码；
健康监测：查看学生每日健康打卡记录，统计异常体温数据，导出健康报表；
出入管理：审批请假申请，登记出/入校记录，关联健康码状态验证；
信息发布：发布疫情动态（城市病例数据），更新防疫知识，管理交流论坛；
数据统计：核酸报告汇总，异常情况预警，生成日/周/月统计报表。

学生端（核心需求功能）

健康打卡：每日上报体温、身体状况、健康码，支持位置打卡；
请假申请：在线提交请假申请（填写事由、时间、地点），查看审批进度；
出入登记：出/入校时扫码登记，关联请假记录验证；
信息查看：浏览疫情动态、防疫知识、系统公告，参与论坛讨论；
核酸报告：上传/查看个人核酸报告，关联出校申请。

2. 需求分析避坑要点（实战经验总结）

聚焦真实场景：调研3-5所高校的防疫流程，收集辅导员、学生的真实痛点。基于“快速定位密接者”需求，增设“打卡地点热力图”功能，实用性远于复杂的预测算法；
绘制业务流程图：使用DrawIO绘制“健康打卡→异常预警→辅导员处理”完整闭环，汇报时直观呈现应急响应机制；
定义数据规则：明确约束条件，如“体温≥37.3℃自动标记异常”“请假时间≤7天”“核酸报告48小时有效”，为开发提供明确依据。

3. 可行性分析：三维度论证，提升说服力

技术可行性：Spring Boot+MySQL技术栈成熟，疫情相关API（如健康码接口）文档完善；需注意避免使用最新Spring Boot 3.x，笔者前期遭遇与JSP整合问题，回退至2.7稳定版后顺利运行；
经济可行性：开发工具全免费，部署成本低（学生服务器约300元/年），实际应用价值高；
操作可行性：界面设计参考“国家政务服务平台”，将高频功能（健康打卡、请假申请）置于首页，新用户5分钟内可完成核心操作。

二、技术选型：稳定优先，避免兼容性问题

前期曾尝试Spring Boot 3.x + Vue 3前后端分离，因疫情数据实时性要求高，前端渲染延迟明显。调整为“Java 8 + Spring Boot 2.7 + MySQL 8.0 + JSP + Bootstrap 3”单体架构，页面响应更快，适合疫情数据快速展示。

1. 核心技术栈选型说明

技术工具	选型理由	避坑提醒
Java 8	校园教学主流，调试工具丰富，疫情数据处理稳定	避免使用Java 11+模块化，依赖配置复杂
Spring Boot 2.7	简化配置，快速搭建REST API，适合打卡数据提交	使用spring-boot-starter-web、spring-boot-starter-data-jpa
MySQL 8.0	支持GIS地理位置存储（打卡地点），性能好	安装时设置字符集utf8mb4，支持Emoji表情
JSP + JSTL	与Spring MVC无缝整合，直接渲染疫情数据表格	避免JSP中写复杂Java代码
Bootstrap 3	提供响应式布局，快速搭建管理后台	使用3.4.1稳定版，兼容IE10+

2. 开发环境搭建步骤（一次成功）

安装JDK 1.8：配置JAVA_HOME，验证java -version；
安装Eclipse 2022：安装Spring Tools 4插件，工作空间编码UTF-8；
安装MySQL 8.0：创建数据库campus_epidemic_system，字符集utf8mb4；
创建Spring Boot项目：

<!-- pom.xml核心依赖 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>8.0.33</version>
    </dependency>
    <!-- JSP支持 -->
    <dependency>
        <groupId>org.apache.tomcat.embed</groupId>
        <artifactId>tomcat-embed-jasper</artifactId>
    </dependency>
</dependencies>

配置application.yml：

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/campus_epidemic_system?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true
    properties:
      hibernate:
        dialect: org.hibernate.dialect.MySQL8Dialect
server:
  port: 8080
  servlet:
    context-path: /epidemic

三、数据库设计：理清防疫关系，避免逻辑漏洞

数据库是系统的核心，前期因“健康打卡表”与“请假表”未建立校验，导致数据矛盾。采用“学生-健康-出入”三层模型后，数据一致性显著提升。

1. 核心表结构设计（共14张表）

学生表(student)：id、student_id、password、name、gender、phone、class、avatar、create_time
健康打卡表(health_clock)：id、student_id、temperature、health_status、is_fever、is_cough、contact_history、location、health_code、clock_time
请假表(leave_apply)：id、student_id、leave_type、start_time、end_time、location、reason、status（0待审核/1通过/2驳回）、audit_remark
出入登记表(access_record)：id、student_id、access_type（1出校/2入校）、access_time、health_code、reason、location
核酸报告表(nucleic_report)：id、student_id、test_location、test_time、report_image、result、create_time
疫情动态表(epidemic_dynamic)：id、city、new_cases、total_cases、cured、deaths、update_time、cover_image
系统公告表(notice)：id、title、content、type、publish_time

关键避坑提醒：体温字段用Decimal类型！初期使用Float存储体温，计算平均值时出现精度误差。后续改为DECIMAL(3,1)，精确到小数点后一位。

2. 表关联测试（业务逻辑验证）

-- 测试：查询今天体温异常（≥37.3℃）且未请假的学生
SELECT s.student_id, s.name, s.class, h.temperature, h.clock_time
FROM health_clock h
JOIN student s ON h.student_id = s.id
LEFT JOIN leave_apply l ON h.student_id = l.student_id 
    AND l.status = 1 
    AND CURDATE() BETWEEN DATE(l.start_time) AND DATE(l.end_time)
WHERE DATE(h.clock_time) = CURDATE()
  AND h.temperature >= 37.3
  AND l.id IS NULL  -- 未在请假期间
ORDER BY h.temperature DESC;

若能正确返回异常学生名单，说明关联逻辑正确；若出现数据矛盾，检查请假时间范围判断逻辑。

四、功能实现：聚焦三个核心模块，突出应急管理

1. 学生端：健康打卡模块（核心必做）

业务逻辑：

每日打卡：学生填写体温（自动校验范围35-42℃）、身体状况（下拉选择）、是否发热/咳嗽、接触史，上传健康码截图，获取当前位置；
异常预警：体温≥37.3℃自动标记“异常”，辅导员端实时提醒；
打卡记录：按日期查看历史记录，支持数据导出。

页面设计：

打卡页：表单分组（基本信息、健康状况、上传区域），带实时校验
记录页：日历视图显示每日打卡状态（绿正常/红异常）
统计页：折线图展示近7天体温变化

技术要点：使用Hibernate Validator进行数据校验：

@Entity
public class HealthClock {
    @NotNull(message = "体温不能为空")
    @DecimalMin(value = "35.0", message = "体温不能低于35℃")
    @DecimalMax(value = "42.0", message = "体温不能高于42℃")
    private BigDecimal temperature;
    
    @NotNull(message = "打卡时间不能为空")
    private LocalDateTime clockTime;
}

2. 学生端：请假申请模块（答辩亮点）

业务逻辑：

在线申请：选择请假类型（事假/病假/外出）、时间范围（开始-结束）、填写事由和目的地；
冲突检测：自动检测与已有请假、课程表的时间冲突；
进度跟踪：实时查看审核状态（待审核/已通过/已驳回），驳回时显示具体原因。

避坑提醒：请假时间重叠检测！初期未检测重叠，导致同一时段多次请假：

public boolean checkLeaveConflict(Long studentId, LocalDateTime newStart, LocalDateTime newEnd) {
    List<LeaveApply> myLeaves = leaveRepo.findByStudentIdAndStatus(studentId, 1); // 已通过请假
    return myLeaves.stream().anyMatch(leave -> {
        // 时间重叠判断：新开始时间在某个请假期间内，或新结束时间在某个请假期间内
        return !(newEnd.isBefore(leave.getStartTime()) || newStart.isAfter(leave.getEndTime()));
    });
}

3. 管理员端：疫情数据看板模块（体现分析能力）

业务逻辑：

实时监控：仪表盘显示今日打卡率、异常体温数、在校人数；
趋势分析：折线图展示近30天体温异常趋势，柱状图显示各班级打卡率；
预警推送：自动向辅导员推送异常学生名单，支持一键导出。

技术实现：使用ECharts轻量级集成：

// 体温异常趋势图
var chart = echarts.init(document.getElementById('chart'));
chart.setOption({
    title: { text: '近30天体温异常趋势' },
    xAxis: { data: dates },
    yAxis: { type: 'value' },
    series: [{
        name: '异常人数',
        type: 'line',
        data: abnormalCounts
    }]
});

在这里插入图片描述

五、测试验收：全面覆盖防疫场景

1. 功能测试用例（重点场景）

测试场景	操作步骤	预期结果
学生请假期间打卡	学生请假3天（已审批）→请假期间尝试打卡	系统提示“您当前处于请假状态，无需打卡”
体温异常上报	学生填报体温37.5℃→提交打卡	系统标记“异常”，辅导员后台收到预警通知
核酸报告过期	学生上传48小时前核酸报告→申请出校	系统提示“核酸报告已过期，请重新检测”

2. 压力测试要点

并发打卡：模拟500学生同时打卡，响应时间应<3秒；
数据导出：导出30天所有打卡记录（约1.5万条），生成Excel时间应<10秒；
内存监控：连续运行24小时，内存占用应稳定在500MB以内。

3. 测试报告规范

发现问题：记录如“请假时间冲突检测漏判跨天情况，已修复”“体温异常推送延迟，优化为实时消息”；
测试结论：“系统满足校园防疫核心需求，健康监测、请假管理、数据统计功能完整，具备上线运行条件”。

六、答辩准备：三个技巧提升通过率

演示剧本设计：
- 场景一：学生端（健康打卡→请假申请→查看公告）
- 场景二：管理员端（审核请假→查看异常数据→发布动态）
- 场景三：应急模拟（模拟体温异常全流程处理）（关键步骤：异常数据标红显示，预警弹窗效果）
突出疫情防控特色：
- 实时性：疫情数据每小时更新，异常情况5分钟预警
- 精准性：基于位置打卡，防止虚假打卡
- 追溯性：完整记录学生行程，便于流调追溯
预设问答准备：
- Q：如何保证打卡数据真实性？ A：三重验证：① 地理位置验证；② 时间频率限制（每人每日一次）；③ 异常数据人工复核
- Q：系统有何实际价值？ A：降低辅导员工作量70%，异常发现时间从小时级降至分钟级，实现校园防疫数字化管理

结语

本文基于Spring Boot+MySQL的校园疫情防控系统实战，系统梳理了从需求到答辩的全流程要点。防疫类毕设核心在于“实时、准确、可追溯”，无需追求复杂功能，将健康监测、出入管理、数据统计做扎实，即可满足答辩要求。

若需要完整源码（含详细注释）、数据库脚本（带模拟数据）、疫情数据API接口，可在评论区留言“疫情防控系统”获取；如在健康打卡逻辑、请假审批等模块遇到问题，也可留言交流。

收藏本文，开发过程中随时查阅～祝各位同学毕设顺利，为校园防疫贡献代码力量！🏫🛡️

附：核心业务SQL片段

-- 每日健康统计报表
SELECT 
    DATE(clock_time) as date,
    COUNT(*) as total_count,
    SUM(CASE WHEN temperature >= 37.3 THEN 1 ELSE 0 END) as abnormal_count,
    ROUND(AVG(temperature), 1) as avg_temperature
FROM health_clock 
WHERE clock_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY DATE(clock_time)
ORDER BY date DESC;

技术栈版本推荐：

Spring Boot: 2.7.18 (LTS版本)
MySQL: 8.0.33
JDK: 1.8.0_381
Bootstrap: 3.4.1
ECharts: 5.4.2 (数据可视化)

开发时间规划：

第1周：需求分析+数据库设计+环境搭建
第2周：学生模块+健康打卡模块
第3周：请假管理+出入登记模块
第4周：数据看板+测试优化+论文撰写

防疫数据源建议：

疫情动态：对接国家卫健委API（免费）
地理位置：使用百度地图API（学生认证免费）
健康码：模拟验证（实际项目需对接政务平台）