毕业设计实战：基于Java+MySQL的高校疫情防控系统设计与实现全流程指南毕业设计实战：基于Java+MySQL的高校

毕业设计实战：基于Java+MySQL的高校疫情防控系统设计与实现全流程指南

在开发“基于Java+MySQL的高校疫情防控系统”毕业设计时，曾因“健康申报信息与学生信息未实时关联”踩过关键坑——初期未建立“学生防控申报表”与“用户表”的实时外键关联，导致管理员查看申报记录时无法同步获取学生姓名、学院、联系方式，需手动在多张表中交叉核对，耗费1.5天重构表结构、补全关联逻辑才解决问题📝。基于此次实战经验，本文将系统拆解从需求分析、技术选型、功能实现到测试验收的全流程要点，附避坑技巧与实操细节，为疫情防控类毕设提供可落地的实施指南。

一、需求分析：锚定高校防疫核心诉求，避免功能冗余返工

部分同学在毕设初期易陷入“功能堆砌”误区，比如笔者曾耗时2天开发“疫情数据可视化大屏模块”，最终因偏离“健康申报、信息审核、公告通知、人员管理”核心需求被导师要求删减。明确“用户角色-核心功能”对应关系，是降低返工率的关键前提。

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

系统核心用户分为学校管理员、学院管理员、教师、学生四类，前期曾因混淆“学院管理员”与“学校管理员”的“跨学院数据查看权限”，导致学院管理员可查看其他学院敏感健康信息，明确角色边界后系统数据安全性显著提升，具体功能分工如下：

学校管理员端（最高权限核心功能）

全角色用户管理：维护学校管理员、学院管理员、教师、学生账号生命周期（新增、密码重置、逻辑删除），支持按姓名/编号/所属学院精准筛选，查看用户完整资料（如学生宿舍号、教师联系方式）；
核心防疫管控：
- 申报信息审核：查看全校师生健康申报记录（体温、咳嗽症状、外出情况）、审核异常申报（标注高风险人员、填写处理意见），确保疫情数据准确；
- 公告信息管理：发布疫情通知（编辑公告标题、类型、详情、上传封面图）、维护公告生命周期（修改、下架），重要通知置顶显示；
数据统计分析：统计各学院申报率、异常率、高风险人员比例，生成“校园疫情防控日报”，支持按时间范围导出数据；
系统日志监控：记录所有用户登录、申报、审核操作，通过日志追溯数据修改历史，确保防疫数据可审计。

学院管理员端（学院级管理功能）

本学院人员管理：管理本学院教师、学生基本信息（查看、编辑基础信息），不可跨学院操作；
申报信息查看：查看本学院师生健康申报记录，标记异常情况，及时上报学校管理员；
公告信息传达：查看学校发布的公告，向本学院师生转发重要通知；
数据统计：统计本学院申报情况，生成学院级防疫报告。

教师端（健康申报与信息查看）

个人健康申报：每日提交健康信息（填写体温、有无咳嗽、有无外出、外出地点、是否接触病患等），历史记录可查；
信息查看：查看学校公告、个人申报历史、学院通知；
个人资料管理：修改联系方式、更新头像，无修改他人数据权限。

学生端（核心申报功能）

每日健康打卡：提交健康申报信息（体温、症状、行程等），支持快速复用昨日信息（优化重复填写体验）；
信息获取：查看学校/学院公告、个人申报记录、防疫政策；
个人资料维护：修改联系方式、更新头像，查看所属学院、宿舍号等固定信息。

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

模拟真实场景：邀请4-5名同学分别扮演“学生每日打卡-学院管理员查看-学校管理员审核”“学校发布紧急通知-各角色接收”场景，收集真实诉求。例如，基于学生“快速完成每日打卡”需求，增设“一键复用昨日健康信息”功能，实用性远高于冗余的“疫情地图可视化模块”；
绘制角色用例图：使用DrawIO工具绘制四类用户的核心业务用例图（如“学生-健康申报”“教师-信息查看”“学院管理员-数据统计”“学校管理员-公告发布”），汇报时直观呈现权限分层逻辑；
明确约束条件：提前规定“体温输入范围（35.0-42.0℃）”“外出地点字数限制（≤50字）”“公告发布后24小时内不可删除”“高风险区域名单动态更新”，为编码提供明确依据，避免功能偏离需求。

3. 可行性分析：从三维度论证，提升毕设专业性

可行性分析是开题关键，需从技术、经济、操作三维度展开，避免泛泛而谈“可行”：

技术可行性：Java、MySQL、Spring Boot、Vue.js均为高校主流技术栈，开发资料丰富（如《Spring Boot实战》《Vue.js前端开发》），技术门槛可控；需注意Spring Boot版本兼容性，笔者前期使用Spring Boot 2.7+与Vue 2联调时，跨域配置频繁报错，切换至Spring Boot 2.5稳定版后问题解决；
经济可行性：开发工具均为免费/开源版本（IDEA社区版、MySQL社区版、VSCode），云端部署可选学生优惠服务器（如阿里云学生机），开发与部署成本极低；系统上线后可替代传统纸质申报，减少人工统计时间，帮助高校实现精准防疫，具备实际应用价值；
操作可行性：界面参考主流健康打卡类应用交互，高频功能（每日申报、公告查看）置于首页显眼位置，经测试，学生用户1分钟内可完成健康打卡操作，教师与管理员3分钟内掌握审核流程，易用性达标。

二、技术选型：优先稳定适配，拒绝盲目追新

前期曾尝试Spring Cloud微服务架构，因服务注册配置复杂，导致健康申报数据同步延迟，调试耗时2天。后续调整为“Spring Boot 2.5 + MySQL 8.0 + Vue 2 + ElementUI”单体应用组合，兼顾稳定性与开发效率，非常适合防疫类系统快速上线。

1. 核心技术栈选型说明（含避坑提醒）

技术工具	选型理由	避坑提醒
Spring Boot 2.5	快速构建RESTful API，内置Tomcat服务器，简化配置（application.yml），与MySQL、Vue.js集成顺畅，适合多角色权限系统开发	避免使用Spring Boot 2.7+版本，部分跨域配置（CorsFilter）与Vue 2前端请求不兼容，易出现“403跨域错误”
MySQL 8.0	支持事务与外键约束，可满足多表关联（如用户-申报记录、公告-发布者），utf8mb4编码解决生僻字乱码，性能满足高校级数据量	安装时手动设置编码为utf8mb4，默认编码会导致公告内容、外出地点含特殊符号时乱码；需开启事务，确保申报记录与用户信息原子性
Vue 2 + ElementUI	前端组件丰富（表单、表格、日期选择器、消息提示），快速构建响应式健康申报界面，支持电脑、手机多端适配，用户体验良好	避免使用Vue 3 + Element Plus，部分组件（如级联选择器）在移动端兼容性差，前期曾导致外出地点选择错乱，切换版本后恢复
IDEA / Eclipse	主流Java开发工具，支持Maven依赖管理、代码调试、数据库连接，插件生态丰富（如MyBatis插件、Vue.js插件）	安装“Lombok”插件避免Getter/Setter代码冗余；配置Maven镜像为阿里云，加快依赖下载速度

2. 开发环境搭建步骤（实操指南）

安装JDK 1.8：记录安装路径（如D:\Java\jdk1.8.0_301），配置“JAVA_HOME”“Path”环境变量，通过cmd命令“java -version”验证；
安装MySQL 8.0：用Navicat或命令行创建数据库“campus_epidemic_control”，设置编码utf8mb4、排序规则“utf8mb4_general_ci”；
创建Spring Boot后端项目：
- 使用Spring Initializr生成项目（选择Web、MyBatis、MySQL Driver依赖），导入IDEA/Eclipse；
- 配置application.yml：数据库连接、服务器端口（如8080）、MyBatis映射路径、日志级别；
创建Vue前端项目：
- 使用Vue CLI创建Vue 2项目（命令“vue create epidemic-frontend”），选择ElementUI插件；
- 配置axios拦截器处理请求响应，封装健康申报、公告查看等API接口；
联调测试：编写“查询学生列表”接口，前端调用后能显示姓名、学院、宿舍号，说明环境搭建成功。

三、数据库设计：理清防疫数据关联逻辑，避免信息孤岛

数据库是高校疫情防控系统的核心骨架，前期因未在“学生防控申报表”与“用户表”间设置实时外键关联，导致无法快速定位未申报学生，需重新编写关联查询SQL才解决问题😓。后续采用“实体-属性-关系”分析法梳理表结构，效率显著提升。

1. 核心实体与属性设计（附ER图绘制技巧）

明确系统核心实体（用户/学生、教师、学校管理员、学院管理员、学生防控申报、教师防控申报、公告信息、学院部门），核心表结构如下（共9张核心表，可直接用于ER图绘制）：

关键表结构（部分核心字段）

用户表（yonghu）：id（主键）、yonghu_name（姓名）、yonghu_phone（手机）、yonghu_suse（宿舍号）、xuanyuan_types（学院ID）、create_time（创建时间）；
学生防控申报表（fangkongshenbao_xuesheng）：id（主键）、yonghu_id（学生ID，外键）、tiwen（体温，Decimal）、keshou_types（咳嗽症状，Integer）、wuaichu_types（有无外出，Integer）、didian（外出地点，String）、insert_time（申报时间）；
教师防控申报表（fangkongshenbao_jiaoshi）：id（主键）、jiaoshi_id（教师ID，外键）、tiwen（体温）、其他健康字段同上；
公告信息表（news）：id（主键）、news_name（标题）、news_types（类型）、news_content（内容）、news_photo（封面图）、insert_time（发布时间）；
学院部门表（字典表关联）：通过xuanyuan_types字段关联字典表，存储学院编号与名称映射。

ER图绘制建议：使用亿图或Visio，遵循3个规则：① 矩形代表实体（如“学生”“健康申报”）；② 椭圆代表属性（如申报表的“体温”“外出地点”“申报时间”）；③ 菱形代表关系（如“学生-健康申报”为一对多，一个学生可有多条申报记录）。

关键避坑提醒：切勿将健康申报附件（如行程码截图）以二进制形式存入数据库！前期尝试该方案导致数据库体积暴增，查询性能下降。后续改为文件路径存储（如/static/health/行程码_20240510.jpg），通过Nginx提供静态资源访问，性能提升显著。

2. 表关联测试：提前验证，避免编码后返工

建表后立即测试关联逻辑，步骤如下：

在用户表插入测试数据：id=1，name=“张三”，xuanyuan_types=1（计算机学院），suse=“A栋101”；
在学生防控申报表插入关联数据：id=1，yonghu_id=1，tiwen=36.5，wuaichu_types=0（无外出），insert_time=“2024-05-10”；
编写JOIN查询SQL，验证“学生健康申报详情与基本信息关联”：

SELECT u.yonghu_name, u.yonghu_phone, u.yonghu_suse,
       d.dic_name AS college_name,
       f.tiwen, f.keshou_types, f.wuaichu_types, f.didian, f.insert_time
FROM yonghu u
JOIN fangkongshenbao_xuesheng f ON u.id = f.yonghu_id
JOIN dictionary d ON u.xuanyuan_types = d.code_index AND d.dic_code = 'xuanyuan_types'
WHERE u.id = 1
ORDER BY f.insert_time DESC;

若能查询出“学生姓名、电话、宿舍、学院名称、体温、症状、外出地点、申报时间”，说明关联正确；若出现外键约束错误，需检查字段类型与索引是否匹配。

四、功能实现：聚焦防疫核心模块，提升答辩竞争力

无需开发所有功能，优先完成3个核心模块即可满足答辩要求，且能突出疫情防控特色：

1. 学生端：每日健康申报模块（必做核心模块）

核心逻辑：
1. 申报发起：学生登录后进入健康申报页，系统自动填充昨日信息（可编辑），填写当日体温（范围校验35.0-42.0℃）、选择有无咳嗽/外出、填写外出地点（若外出），提交后状态记为“已申报”；
2. 历史查看：在“我的申报”页面按时间倒序展示历史记录，支持按日期筛选，异常申报（体温≥37.3℃或有咳嗽）标红显示；
3. 缺勤提醒：若当日未申报，首页显示醒目提醒，并记录缺勤次数（用于学院管理员统计）。
页面设计（Vue 2+ElementUI）：
- 申报表单区：体温输入框（带小数点校验）、咳嗽单选组、外出单选组（动态显示外出地点输入框）、提交按钮；
- 历史列表区：表格展示申报日期、体温、症状、外出地点，操作列含“查看详情”；
- 缺勤提示区：悬浮提示框，显示“今日尚未申报，请及时完成健康打卡”。

2. 学校管理员端：公告信息管理模块（信息传达核心）

核心逻辑：
1. 公告发布：填写公告标题、选择类型（通知/政策/紧急）、上传封面图、编辑详情（富文本编辑器），支持定时发布与立即发布；
2. 公告管理：列表展示所有公告，支持按标题搜索、按类型筛选，可进行编辑、下架（逻辑删除）、置顶操作；
3. 发布统计：统计各类公告发布数量、阅读量（需结合前端埋点），生成“公告影响力报表”。
页面设计：
- 发布区：表单弹窗包含标题输入框、类型下拉框、封面图上传、富文本编辑域、发布按钮；
- 管理列表区：表格展示公告标题、类型、发布时间、状态，操作列含“编辑”“下架”“置顶”；
- 统计卡片：展示“总公告数”“紧急通知数”“当月发布数”等关键指标。

3. 学院管理员端：健康数据统计模块（防疫管控亮点）

核心逻辑：
1. 本学院数据概览：首页卡片展示“本学院今日申报率”“异常申报数”“高风险人员数”；
2. 明细查看：查看本学院学生/教师申报明细，支持按姓名、日期、异常状态筛选，导出Excel报表；
3. 缺勤追踪：查看本学院未申报人员列表，一键发送提醒消息（集成邮件或站内信）。
页面设计：
- 数据概览区：三个统计卡片（申报率、异常数、高风险数），环形进度条展示申报率；
- 明细表格区：分页表格展示申报明细，异常行标红，支持导出按钮；
- 缺勤列表区：表格展示未申报人员姓名、班级、联系方式，操作列含“发送提醒”。

五、测试验收：全面排查防疫场景，保障系统稳定

笔者前期未测试“学生重复提交当日申报”场景，导致同一日生成多条申报记录，被导师指出“未做每日限次校验”并扣分😥。需针对性完成以下测试：

1. 核心功能测试用例

测试场景	操作步骤	预期结果
学生重复提交当日健康申报	学生登录→提交健康申报→再次进入申报页提交	系统提示“今日已申报，不可重复提交”，提交按钮禁用
学校管理员发布紧急公告	管理员进入公告管理→选择“紧急”类型→填写内容→发布	公告立即出现在所有用户首页置顶位置，并有红色“紧急”标识
体温输入异常值	学生申报时输入体温“34.5”或“43.0”	系统提示“体温需在35.0-42.0℃之间”，提交失败

2. 并发与性能测试

并发申报：用Jmeter模拟1000名学生同时提交健康申报，系统响应时间≤3秒，数据无丢失；
大数据量查询：测试10万条申报记录下，学院管理员按日期筛选查询，耗时≤2秒；
移动端适配：测试iOS/Android主流浏览器，申报表单无布局错乱，按钮点击灵敏。

3. 测试报告撰写

包含“测试目的、范围、用例、结果、问题总结”，明确已修复问题（如重复申报校验、移动端样式优化），结论需说明“核心健康申报、公告管理、数据统计功能运行稳定，可满足高校日常疫情防控管理需求”。

六、答辩准备：掌握3个技巧，突出防疫特色

演示流程梳理：按“学生每日健康打卡→学院管理员查看本学院数据→学校管理员发布紧急公告→各角色接收通知”主线演示，突出疫情信息流闭环；
突出问题解决能力：重点讲“健康申报与人员信息关联优化”“每日限次申报防重复机制”“高并发申报性能调优”，体现实际开发深度；
提前预判问题：针对“如何保证申报数据真实”，回答“结合地理位置校验（可选）、申报时间规律分析、后台数据一致性核查”；针对“如何应对突发疫情”，回答“紧急公告一键推送、高风险人员快速筛查、申报数据实时统计”。

结语

本文基于Java+MySQL高校疫情防控系统的实战经验，核心是“聚焦健康申报核心流程、确保数据实时关联、优化多角色协作”。毕设无需追求复杂功能（如人脸识别测温对接、疫情预测模型），把每日申报、公告通知、数据统计等核心功能做扎实，即可顺利通过答辩。

若需要核心源码（带注释）、数据库脚本（含测试数据）、防疫场景测试用例，可在评论区留言“Java+MySQL疫情防控系统”获取；若在健康申报模块或权限控制中遇问题，也可留言咨询，笔者将及时回复。

收藏本文，便于开发查阅～祝各位同学毕设顺利，健康毕业！🎉