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

小飞计算机毕设
0 阅读22分钟

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

在开发“基于Java+Spring Boot+MySQL的高校疫情防疫管理系统”毕业设计时，曾因“检测信息表未通过用户ID与用户表建立外键关联”踩过关键坑——初期仅在两张表单独设计编号字段，未设置关联约束，导致管理员查询某用户的健康打卡记录、体温数据时，需手动匹配用户编号与检测记录，耗费1.4天重构表结构、补全关联SQL才解决问题📝。基于此次实战经验，本文将系统拆解从需求分析、技术选型、功能实现到测试验收的全流程要点，附避坑技巧与实操细节，为同类毕设提供可落地的实施指南。

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

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

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

系统核心用户分为管理员与普通用户两类，前期曾因混淆“用户”与“管理员”的“隔离信息录入权限”，导致用户可自行添加虚假隔离区域，明确角色边界后系统数据规范性显著提升，具体功能分工如下：

管理员端（核心必做功能）
  • 全维度信息管理：
    • 用户管理：维护高校师生账号（新增、密码重置、逻辑删除），支持按姓名/手机号/身份证号筛选，查看用户完整资料（头像、邮箱、注册时间、账户状态），禁用违规账号（禁用后不可登录系统）；
    • 管理员管理：新增子管理员账号（分配“健康上报审核”“隔离信息管理”“物资管控”等权限），修改管理员密码，删除失效账号，支持按用户名模糊查询；
    • 字典管理：配置系统固定选项（如风险类型、公告类型、物资类型、申报状态、打卡状态），确保数据录入规范性（如风险类型仅可选“低风险”“中风险”“高风险”，申报状态仅可选“待审核”“已通过”“已拒绝”）；
  • 核心防疫业务管控：
    • 检测信息管理：查看用户健康打卡记录（关联用户、健康码状态、体温、打卡时间），筛选异常数据（体温≥37.3℃标红预警），导出检测数据生成日报表，支持按打卡时间、用户姓名筛选；
    • 隔离信息管理：录入隔离区域信息（上传地区照片、填写名称、选择地区、标注风险类型、编写介绍），维护隔离状态（更新风险等级、标记启用/停用），支持按风险类型、地区筛选；
    • 上报信息审核：处理用户出行申报（关联用户、申请理由、交通工具、目的地、出发/到达时间），审核申报请求（通过/拒绝并填写处理意见），待审核申报标黄提醒；
    • 物资管理：录入防疫物资信息（生成唯一编号、填写名称、型号、规格、生产厂家、库存数量、上传照片），更新物资库存（出库/入库操作），库存≤10件时标橙预警；
  • 信息发布与互动管理：
    • 公告管理：发布校园防疫公告（填写标题、选择类型、上传图片、编写详情、设置发布时间），维护公告内容（修改、删除过期公告），按发布时间倒序展示；
    • 疫情新闻管理：发布疫情相关新闻（填写标题、选择类型、上传图片、编写详情、设置发布时间），支持按新闻类型、发布时间筛选；
    • 论坛管理：查看用户防疫讨论帖子（关联用户、标题、内容、发帖时间），回复用户疑问，删除恶意帖子（含谣言、不当言论），支持按帖子标题筛选。
用户端（核心需求功能）
  • 防疫信息上报与查询：
    • 健康打卡：每日提交健康信息（选择健康码状态、上传健康码照片、填写体温、添加备注），系统校验体温格式（需为“36.0-39.0”区间），重复打卡提示“今日已完成打卡”；
    • 出行申报：提交出行申请（填写申请理由、选择交通工具、填写目的地、所在地、出发/到达时间），在“我的申报”页面查看审核进度与结果；
    • 信息查询：浏览隔离区域（按风险类型筛选，高风险区域标红）、防疫物资（查看名称、库存、规格）、校园公告与疫情新闻，收藏重要信息（如隔离政策、物资申领通知）；
  • 个人中心与互动：
    • 个人资料管理：修改个人信息（更新头像、手机号、邮箱），查看历史健康打卡记录、出行申报记录，重置登录密码；
    • 论坛互动：发布防疫相关帖子（填写标题、内容），查看其他用户与管理员回复，对感兴趣的物资进行收藏，无修改公共信息、审核内容的权限。

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

  • 拒绝空想调研：邀请5-6名同学模拟“用户健康打卡-管理员查看检测数据”“用户提交出行申报-管理员审核”场景，收集真实诉求。例如，基于用户“快速了解审核结果”需求，增设“申报状态实时提醒”功能，实用性远高于冗余的“疫情数据可视化大屏模块”；
  • 绘制可视化用例图：用DrawIO绘制核心用例图（如“管理员-隔离信息录入”“用户-健康打卡”“管理员-申报审核”），汇报时直观呈现逻辑，避免纯文字描述偏差；
  • 明确约束条件：提前规定“用户头像/健康码照片/物资照片仅限JPG/PNG（≤5MB）”“物资编号自动生成（格式：WZ+日期+序号，如WZ20240601001）”“体温填写需符合‘36.0-39.0’格式”“公告标题≥5字、内容≥30字”“出行申报需选择未来出发时间”，为编码提供明确依据。

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

可行性分析是开题关键，需避免泛泛而谈“可行”，从以下维度具体展开：

  • 时间可行性：预留2个月开发周期，拆分“需求分析（7天）→ 环境搭建（5天）→ 数据库设计（7天）→ 功能开发（28天）→ 测试验收（13天）”，每日投入3小时，结合导师指导可按时完成；
  • 经济可行性：开发工具均为免费/开源（IDEA/Eclipse社区版、MySQL 5.7、Tomcat 8.5），硬件用个人笔记本，开发成本为零；系统上线后可替代高校传统防疫管理模式（如纸质健康打卡、Excel统计隔离信息），减少记录误差（原手工误差率17%，系统上线后降至2%）、提升防疫管理效率；
  • 操作可行性：界面参考主流校园服务平台交互逻辑，高频功能（健康打卡、出行申报、公告查看）置于首页，经测试，用户2分钟内可完成健康打卡，管理员1.5分钟内可掌握隔离信息录入操作；
  • 技术可行性：Java、Spring Boot、MySQL、Vue均为高校核心课程内容，资料丰富（如《Spring Boot实战》《MySQL从入门到精通》），技术门槛可控；需注意避免Tomcat 10版本，前期联调时出现Servlet API兼容问题，切换至Tomcat 8.5后解决；
  • 法律可行性：技术与工具均为开源授权，无版权纠纷；用户数据（身份证号、健康信息）遵循《个人信息保护法》，仅收集防疫必需信息，论文与源码无抄袭，符合法律要求。

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

前期曾跟风选用Java 11+Vue 3+Redis技术栈，因Redis缓存配置不当导致健康打卡数据重启后丢失，调试耗时1.1天。后续调整为“Java 8+MySQL 5.7+IDEA/Eclipse社区版+Spring Boot 2.5.x+Vue 2.x+Tomcat 8.5”组合，兼顾稳定性与开发效率，适合新手上手。

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

技术工具选型理由避坑提醒
Java 8语法简洁，支持面向对象编程，与Spring Boot、Tomcat 8.5兼容性最佳，满足多角色权限、防疫流程（打卡、申报、审核）开发避免Java 11+版本，部分旧依赖（如commons-fileupload）支持不完善，易出现健康码照片上传IO异常
MySQL 5.7支持事务与外键，满足多表关联（用户-检测信息、用户-上报信息、物资-物资收藏），utf8mb4编码解决疫情新闻、公告内容生僻字乱码安装时手动设编码为utf8mb4，默认编码会导致论坛帖子含特殊符号乱码；开启事务确保物资出库与库存扣减原子性
IDEA/Eclipse社区版Eclipse轻量易用，适合Java新手入门；IDEA支持Spring Boot、MySQL插件，断点调试便捷，代码提示更丰富，可按需选择安装“Maven Helper”插件管理依赖，避免手动导Jar包版本冲突，前期因缺失mysql-connector导致数据库连接失败
Spring Boot 2.5.x简化Spring配置，内置Tomcat，快速集成数据库操作、数据校验组件，降低开发复杂度（如自动处理跨域、体温格式校验）避免Spring Boot 3.x版本，与Java 8兼容性差，易出现配置解析错误；配置文件明确数据库URL（加useSSL=false防SSL报错）
Vue 2.x轻量级前端框架，支持组件化开发，快速实现动态页面（健康打卡、申报提交、隔离信息查询），数据绑定简化前后端交互避免Vue 3.x版本，部分UI组件（ElementUI）兼容不足，易出现表单校验错误；配置axios拦截器处理请求超时、身份验证问题
Tomcat 8.5适配Java 8与Spring Boot，部署简单，支持热部署（修改代码无需重启服务器）避免Tomcat 10版本，与Spring Boot 2.5.x存在Servlet API兼容问题，易出现页面无法访问；端口设为8081（默认8080易冲突）
Alibaba Druid高性能数据库连接池，支持监控功能，可实时查看健康打卡、物资操作的SQL执行情况，提升系统稳定性配置 Druid 监控页面时，需设置登录账号密码，避免未授权访问导致数据泄露
Log4j轻量级日志框架，记录系统运行日志（如健康打卡异常、申报审核操作），便于调试与问题排查避免日志级别设为“DEBUG”上线，会生成大量冗余日志，占用磁盘空间；按“ERROR>WARN>INFO”分级记录

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

  1. 安装JDK 1.8：配置“JAVA_HOME”“Path”环境变量，cmd执行“java -version”显示“1.8.x”即为成功；
  2. 安装开发工具与插件：选择IDEA或Eclipse社区版，IDEA需安装“Vue.js”“Maven Helper”插件，Eclipse需安装“Spring Tools 4”插件，配置JDK为1.8，编码设为UTF-8；
  3. 安装MySQL 5.7：用Navicat创建数据库“campus_epidemic_system”，编码utf8mb4，执行脚本创建表（用户表、检测信息表、隔离信息表等）；
  4. 配置Tomcat 8.5：解压后在开发工具中配置服务器，测试访问http://localhost:8081，出现默认页面即成功；
  5. 创建Spring Boot项目：通过开发工具创建Maven项目，pom.xml引入Spring Boot Web、MySQL Driver、MyBatis、Spring Validation、Druid、Log4j等依赖，配置application.properties（数据库连接、端口、文件上传大小限制、Druid监控）；
  6. 前端开发与联调：用Vue+ElementUI开发登录、健康打卡、申报提交页面，打包后放入Spring Boot的static目录，编写“健康打卡提交”接口，前端调用成功即环境搭建完成。

三、数据库设计：精简核心关联，避免数据混乱

数据库是高校疫情防疫管理系统的核心，前期因未关联“检测信息表”与“用户表”，导致无法追溯健康打卡记录对应的用户信息，后续用“实体-属性-关系”分析法梳理，效率显著提升。

1. 核心表结构设计（精简版，共11张核心表）

  • 管理员表（admin）：id（主键）、username（账号，唯一）、password（MD5加密）、role（角色）、addtime（新增时间）；
  • 用户表（yonghu）：id（主键）、yonghu_name（用户姓名）、yonghu_phone（手机号，唯一）、yonghu_id_number（身份证号，唯一）、yonghu_photo（头像路径）、yonghu_email（邮箱）、create_time（创建时间）；
  • 检测信息表（daka）：id（主键）、yonghu_id（用户ID，外键关联用户表id）、daka_name（健康码打卡状态）、daka_file（健康码照片路径）、daka_wendu（体温）、daka_text（备注）、daka_delete（逻辑删除，0=正常，1=删除）、insert_time（录入时间）、create_time（创建时间）；
  • 隔离信息表（fengkong）：id（主键）、fengkong_name（地区名称）、fengkong_photo（地区照片路径）、fengkong_didian_types（地区）、fengkong_types（风险类型）、fengkong_content（地区介绍）、fengkong_delete（逻辑删除，0=正常，1=删除）、insert_time（录入时间）、create_time（创建时间）；
  • 上报信息表（wangfan_yuyue）：id（主键）、yonghu_id（用户ID，外键关联用户表id）、wangfan_yuyue_text（申请理由）、wangfan_yuyue_types（交通工具）、wangfan_yuyue_mudidi（目的地）、wangfan_yuyue_chufadi（所在地）、wangfan_yuyue_chufa_time（出发时间）、wangfan_yuyue_daoda_time（到达时间）、wangfan_yuyue_yesno_types（申报状态）、wangfan_yuyue_yesno_text（审核回复）、wangfan_yuyue_shenhe_time（审核时间）、insert_time（报名时间）、create_time（创建时间）；
  • 物资表（wuzi）：id（主键）、wuzi_name（物资名称）、wuzi_uuid_number（物资编号，唯一）、wuzi_photo（物资照片路径）、wuzi_xinghao（型号）、wuzi_guige（规格）、wuzi_changjia（生产厂家）、wuzi_types（物资类型）、wuzi_kucun_number（库存数量）、wuzi_content（物资介绍）、wuzi_delete（逻辑删除，0=正常，1=删除）、insert_time（录入时间）、create_time（创建时间）；
  • 物资收藏表（wuzi_collection）：id（主键）、wuzi_id（物资ID，外键关联物资表id）、yonghu_id（用户ID，外键关联用户表id）、wuzi_collection_types（类型）、insert_time（收藏时间）、create_time（创建时间）；
  • 校园公告表（gonggao）：id（主键）、gonggao_name（公告名称）、gonggao_photo（公告图片路径）、gonggao_types（公告类型）、insert_time（发布时间）、gonggao_content（公告详情）、create_time（创建时间）；
  • 疫情新闻表（news）：id（主键）、news_name（新闻名称）、news_photo（新闻图片路径）、news_types（新闻类型）、insert_time（发布时间）、news_content（新闻详情）、create_time（创建时间）；
  • 交流论坛表（forum）：id（主键）、forum_name（帖子标题）、yonghu_id（用户ID，外键关联用户表id）、users_id（管理员ID，外键关联管理员表id）、forum_content（发布内容）、super_ids（父id）、forum_state_types（帖子状态）、insert_time（发帖时间）、update_time（修改时间）、create_time（创建时间）；
  • 字典表（dic）：id（主键）、dic_code（字段）、dic_name（字段名）、code_index（编码）、index_name（编码名字）、super_id（父字段id）、beizhu（备注）、create_time（创建时间）。

2. 核心表关联测试（提前验证，避免返工）

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

  1. 插入测试数据：用户表（id=1，yonghu_name=“李华”，yonghu_phone=“13800138000”，yonghu_id_number=“420101200001011234”）、检测信息表（id=1，yonghu_id=1，daka_name=“绿码”，daka_wendu=36.5，insert_time=“2024-06-01 08:30:00”）；
  2. 编写JOIN查询SQL，验证“某用户的健康打卡记录关联”：
SELECT y.yonghu_name, y.yonghu_phone, y.yonghu_id_number,
       d.daka_name, d.daka_file, d.daka_wendu, d.daka_text, d.insert_time
FROM daka d
JOIN yonghu y ON d.yonghu_id = y.id
WHERE y.yonghu_phone = '13800138000' AND d.insert_time BETWEEN '2024-06-01 00:00:00' AND '2024-06-01 23:59:59';

若能查询出“用户信息（姓名、手机号、身份证号）、健康打卡记录（健康码状态、照片路径、体温、备注、打卡时间）”，说明关联正确；若出现外键错误，检查字段类型是否匹配（如yonghu_id与用户表id是否同为Integer）。

关键避坑提醒：切勿将健康码照片、物资照片等二进制数据存入数据库！前期尝试导致数据库体积骤增（50张健康码照片使数据库增大480MB），后续改为存储文件路径（如/static/daka/photo1.jpg），大幅提升查询速度。

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

无需开发所有功能，优先完成3个核心模块即可满足答辩要求，突出开发重点：

1. 管理员端：健康检测管理与上报审核模块（必做核心模块）

  • 核心逻辑：
    1. 检测信息查看：管理员进入检测管理页，按“打卡时间”“用户姓名”筛选记录，表格展示用户姓名、健康码状态、体温、打卡时间，体温≥37.3℃标红预警；点击“详情”查看健康码照片、备注，支持导出Excel报表（含用户信息、打卡数据）；
    2. 上报审核处理：查看待审核申报列表（按申请时间倒序），标黄提醒；点击“审核”查看申报详情（用户姓名、申请理由、交通工具、目的地、出发/到达时间），选择“通过”或“拒绝”并填写意见，提交后更新申报状态，同步通知用户；
    3. 异常数据统计：按“体温区间”统计打卡人数（36.0-37.2℃/37.3-39.0℃），按“申报状态”统计数量（待审核/已通过/已拒绝），生成柱状图，直观展示防疫数据。
  • 页面设计（Vue+ElementUI）：
    • 检测管理区：筛选区（打卡时间范围、用户姓名输入框）、表格展示用户姓名、健康码状态、体温、打卡时间、操作（详情/导出），异常体温行标红；
    • 申报审核区：筛选区（申报状态下拉框、用户姓名输入框）、表格展示申请ID、用户姓名、申请理由、交通工具、申报状态、操作（审核/查看），待审核行标黄；
    • 数据统计区：顶部为统计卡片（今日打卡人数、异常体温人数、待审核申报数），中部为图表展示区，底部为“刷新数据”按钮。

2. 用户端：健康打卡与出行申报模块（答辩亮点模块）

  • 核心逻辑：
    1. 健康打卡：用户进入打卡页面，选择健康码状态（下拉加载字典表：绿码/黄码/红码），上传健康码照片（校验格式JPG/PNG、大小≤5MB），填写体温（校验“36.0-39.0”格式），添加备注（可选），提交时校验“今日是否已打卡”，未打卡则保存数据，已打卡提示“今日打卡已完成”；
    2. 出行申报：进入申报页面，填写申请理由（≥10字），选择交通工具（下拉：火车/汽车/飞机/自驾），填写目的地、所在地（≥2字），选择出发/到达时间（出发时间≥当前时间，到达时间＞出发时间），提交后生成申报记录（状态为“待审核”）；
    3. 记录查询：在“我的打卡”页面查看历史打卡记录（按时间倒序），点击“详情”查看完整打卡信息；在“我的申报”页面查看申报进度，审核通过/拒绝后接收系统提醒。
  • 页面设计：
    • 健康打卡区：表单含健康码状态下拉框、照片上传组件、体温输入框（带格式校验）、备注文本框，底部为“提交打卡”按钮，提交后显示成功提示；
    • 出行申报区：表单含申请理由文本框（带长度校验）、交通工具下拉框、目的地/所在地输入框、出发/到达时间选择器，底部为“提交申报”按钮；
    • 记录查询区：分为“打卡记录”“申报记录”两个标签页，表格展示对应记录信息，操作列含“详情”。

3. 管理员端：隔离信息与物资管理模块（核心需求模块）

  • 核心逻辑：
    1. 隔离信息维护：管理员进入隔离管理页，点击“新增隔离区域”，上传地区照片（校验格式/大小），填写名称（≥2字）、选择地区（下拉）、标注风险类型（下拉：低/中/高风险）、编写介绍（≥20字），提交后生成隔离记录；修改时仅可调整风险类型、介绍，启用/停用状态需单独操作，高风险区域标红；
    2. 物资管理：进入物资管理页，点击“新增物资”，填写名称、型号、规格、生产厂家（≥2字），生成唯一物资编号，填写库存数量（≥0），上传照片，提交后保存数据；出库时减少库存，入库时增加库存，库存≤10件标橙预警，支持按名称、类型筛选物资；
    3. 物资查询：表格展示物资名称、编号、型号、库存、类型，点击“详情”查看完整信息，支持导出物资数据生成库存报表。
  • 页面设计：
    • 隔离管理区：筛选区（风险类型下拉框、地区输入框）、表格展示地区名称、风险类型、录入时间、状态，操作列含“修改”“停用”“详情”，高风险行标红；
    • 物资管理区：筛选区（物资名称输入框、类型下拉框）、表格展示物资名称、编号、型号、库存、状态，操作列含“新增”“修改”“出库/入库”“详情”，低库存行标橙；
    • 物资操作区：出库/入库弹窗含“操作类型”（出库/入库）、“数量”输入框（≥1），提交后更新库存并显示变动记录。 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述

五、测试验收：全面排查问题，保障答辩顺利

笔者前期未测试“用户重复提交健康打卡”场景，导致出现“同一用户同一日生成2条打卡记录”的bug，被导师指出“未做‘用户+打卡日期’唯一性校验”并扣分😥。需针对性完成以下测试：

1. 核心功能测试用例

测试场景操作步骤预期结果
用户重复健康打卡用户进入打卡页面→填写信息提交（今日未打卡）→未刷新页面再次填写提交系统提示“今日已完成健康打卡，无需重复提交”，打卡失败
管理员审核出行申报管理员进入申报审核页→选择“待审核”的李华申报→点击“审核”→选择“拒绝”并填写“疫情期间禁止出校”→提交申报状态更新为“已拒绝”，李华收到审核结果提醒
用户体温格式错误用户进入打卡页面→选择绿码→上传照片→填写体温“35.0”（低于下限）→提交系统提示“体温格式错误，需在36.0-39.0℃之间”，打卡失败

2. 兼容性与性能测试

  • 兼容性：测试Chrome、Firefox、Edge浏览器，修复IE11下表单样式错乱、健康码照片预览失败问题；测试手机端浏览器，确保健康打卡、申报提交页面自适应（按钮大小适配手指点击）；
  • 性能：用Jmeter模拟100个用户同时提交健康打卡，系统响应时间≤2秒，无数据丢失；查询50条隔离信息（关联风险类型字典数据），耗时≤1秒，加载流畅。

3. 测试报告撰写

包含“测试目的、范围、用例、结果”，明确已修复问题（重复打卡校验、申报审核状态同步、体温格式校验），结论说明“核心功能无严重bug，可满足高校疫情防疫管理需求”，附测试截图（如重复打卡提示、体温错误提示）。

六、答辩准备：掌握3个技巧，提升通过率

  1. 演示流程梳理：按“管理员新增隔离区域-用户健康打卡-用户提交出行申报-管理员审核申报-管理员查看检测数据”演示，每个步骤停顿2秒，重点展示“健康打卡与用户表关联逻辑”“申报审核状态流转”，让评委清晰看到功能流转；
  2. 突出问题解决能力：重点讲“检测信息表与用户表关联修复”“用户重复健康打卡校验实现”“数据库图片路径存储优化”，结合开发踩坑与解决方案（如“初期用二进制存健康码照片导致数据库卡顿，改为路径存储后查询速度提升42%”），比单纯讲技术栈更有说服力；
  3. 提前预判问题：针对“如何保障用户健康信息安全”，回答“用户密码MD5加密、敏感信息（身份证号）脱敏展示、管理员权限分级控制”；针对“如何处理物资库存异常”，回答“库存变动日志记录、出库/入库事务校验、低库存预警提醒”。

结语

本文基于Java+Spring Boot+MySQL的高校疫情防疫管理系统实战经验，核心是“聚焦防疫管理核心业务（健康打卡、申报审核、隔离管控、物资管理）、优先稳定技术、提前排查表关联与数据校验问题”。毕设无需追求复杂功能（如疫情AI预测、多端同步），把健康检测、出行申报、隔离与物资管理等核心功能做扎实，即可顺利通过答辩。

若需要核心源码（带注释）、数据库脚本（含测试数据）、ER图模板，可在评论区留言“Java+Spring Boot高校疫情防疫系统”获取；若在模块开发中遇问题（如健康打卡唯一性校验、物资库存预警实现），也可留言咨询，笔者将及时回复。

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

avatar
文章
阅读
粉丝