1. 为什么高校疫情管理需要一套独立系统：项目背景与选型逻辑
高校的疫情防控和其他场景不太一样，核心差异在于人员密度高、流动性大、身份主体明确。一个校区动辄上万名学生，加上教职工、后勤人员、临时访客，每天的健康数据、出入记录、异常上报如果靠微信群接龙或者Excel表格汇总，信息滞后不说，还容易漏报错报。疫情管理系统的核心价值不是"做了个网页"，而是把健康状态、活动轨迹、异常处置这三件事串成一条完整的业务闭环。
很多刚接触Java Web开发的同学，第一反应是"这不就是一个CRUD系统吗"。这话对了一半，疫情管理系统确实大量依赖增删改查，但难点在数据之间的关联关系：一个学生的健康打卡记录需要关联他的所属学院、班级、宿舍楼栋；一次异常上报需要联动生成隔离观察记录，同时通知辅导员；每天的出入校审批需要校验当日健康状态是否符合通行条件。这些业务约束才是系统真正的复杂度来源，也是面试官或答辩老师最感兴趣的部分。
选型方面，这套系统用的是SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，属于目前Java Web项目里非常主流、也非常"稳妥"的组合。为什么说稳妥？因为这几个技术栈在社区里的资料最多、踩坑记录最全，对于课程设计和毕业设计而言，遇到问题能搜到解决方案比什么都重要。SpringBoot2负责后端接口的快速搭建，Vue3负责前端页面的交互呈现，MyBatis-Plus把最常见的单表操作省到极致，MySQL8.0提供稳定的事务支持和JSON字段能力。每个组件都不过度复杂，但组合起来恰好够用。
这套系统适合谁？准备毕业设计的计算机相关专业学生、想快速上手前后端分离项目的初级开发、以及需要给学校做一个轻量管理后台的运维同学。下面我会把系统的功能设计、技术细节、部署过程和踩坑经验完整拆开来讲，照着做基本能跑通。
2. 功能地图与数据模型：先想清楚要管什么，再写代码
2.1 三类角色和各自的核心操作
高校疫情管理的用户身份天然分成三层：学生、教职工（辅导员/教师）、系统管理员。三种角色看到的界面和能做的操作完全不同，这是系统设计的第一步。
学生端的核心操作是：每日健康打卡（填报体温、健康状况、是否接触过风险区域）、出入校申请（离校报备、返校申请）、查看个人健康状态和异常通知。教职工端的核心操作是：查看所带班级/学院学生的健康数据、处理异常上报、审批出入校申请、查看统计报表。管理端的核心操作是：用户管理、楼栋/宿舍信息维护、健康数据全量查看、公告发布、基础参数配置（比如风险区域名单、打卡时间窗口）。
这里有个设计细节值得注意：打卡数据要区分"已提交"和"未提交"，而不仅仅是存一个打卡表。系统需要每天定时统计哪些人没有打卡，生成未打卡名单推送给辅导员。这就意味着数据库设计时不能只设计一张"打卡记录"表，还需要一个定时任务去比对用户表和打卡表。
2.2 核心表的字段设计与关联关系
我按实际开发时的习惯，把表拆成四组：用户体系、健康业务、出入管理、系统支撑。
用户体系包括用户表（user）、学院表（college）、班级表（clazz）、宿舍楼栋表（building）、宿舍表（dormitory）。用户表除了账号密码，还要挂上学院ID、班级ID、宿舍ID，这样查一个人的完整信息时能顺藤摸瓜关联出一串数据。
健康业务包括每日打卡表（health_check）、异常上报表（abnormal_report）、隔离观察表（isolation_record）。打卡表的核心字段是：用户ID、打卡日期、体温值、是否咳嗽/乏力（用int类型0或1存储）、是否接触风险区域、健康码颜色、打卡时间。业务上记得加唯一约束（user_id + check_date），防止同一个人同一天重复提交。
出入管理包括出入校申请表（access_apply）、审批记录表（approval_record）。申请表的状态字段是关键：待审批、辅导员通过、辅导员驳回、管理员最终确认。审批记录表不仅能追溯每一步谁做了什么操作，也方便前端展示审批进度。
系统支撑包括公告表（notice）、操作日志表（operation_log）。操作日志很容易被忽略，但答辩时老师很喜欢问"如何追溯某个管理员改了哪些数据"，有一张日志表就能从容应对。
2.3 状态流转的设计思路
业务上最核心的状态流转是"异常处理闭环"：学生打卡时体温异常或勾选咳嗽等症状 -> 系统自动生成异常上报记录 -> 通知辅导员核实 -> 辅导员确认后进入隔离观察流程 -> 隔离期满且连续打卡正常后解除。每一步对应一个状态值，表设计时用status字段标记，前端根据状态值渲染不同的操作按钮。这个状态机设计在答辩时很有讲头，建议在文档里画一个状态流转表。
异常上报状态：0-待核实，1-核实中，2-确认异常，3-排除异常，4-解除观察3. 后端落地：SpringBoot2与MyBatis-Plus的工程化实践
3.1 项目分层结构与包命名规范
拿到源码后第一步不是急着启动，而是先看包结构。合理的分层决定了后续维护体验。这个项目的后端遵循标准的三层架构：Controller（接口层）-> Service（业务层）-> Mapper（数据层），外加entity（实体类）、dto（传输对象）、vo（视图对象）、config（配置类）、common（通用类）、utils（工具类）。
commons包下放统一返回结果类Result、异常处理类GlobalExceptionHandler、业务异常类BusinessException。这三个类值得所有Java Web项目都配一套。统一返回结构最简单也最实用的是：code（状态码）、message（提示信息）、data（数据体）。前端axios拦截器统一判断code是否为200，省得每个接口单独处理异常。GlobalExceptionHandler用@RestControllerAdvice注解，能捕获Service层抛出的业务异常，转成统一格式返回。这个小设计能让Controller代码干净很多，业务里只需要throw new BusinessException("该日期已打卡")即可。
3.2 MyBatis-Plus的常规操作与自定义SQL边界
MyBatis-Plus对单表CRUD的简化非常夸张。继承BaseMapper 后，insert、deleteById、selectById、selectList等常用方法直接可用。配合ServiceImpl和IService接口，Service层也省了大部分基础增删改查代码。实际开发里我总结了一个经验：能用BaseMapper解决的操作绝不自写SQL，只有多表关联查询或复杂统计时才上自定义XML。
以每日打卡为例，单表插入就是一行：
healthCheckMapper.insert(healthCheck);但"查询某学院今日未打卡学生名单"就需要多表关联了。这个SQL我建议写在XML文件里，Mapper接口只定义方法。
<select id="selectUncheckedStudents" resultType="com.example.entity.UserInfo"> SELECT u.id, u.real_name, u.college_id FROM user u WHERE u.college_id = #{collegeId} AND u.role_type = 'student' AND u.id NOT IN ( SELECT hc.user_id FROM health_check hc WHERE hc.check_date = #{today} ) </select>MyBatis-Plus还有一个容易被低估的功能：条件构造器Wrapper。动态条件查询用lambdaQuery()非常舒服，不用写SQL，也不怕字符串拼错。官方建议在service层用LambdaQueryWrapper做动态条件组装，比如出入校申请按状态筛选：
LambdaQueryWrapper<AccessApply> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StringUtils.hasText(status), AccessApply::getStatus, status) .eq(userId != null, AccessApply::getUserId, userId);这段代码的精髓在eq方法的第一个参数：当条件为false时，这个查询条件自动跳过，天然支持了"前端没传这个筛选条件就不加这个where"。比一个个if判断写起来干净得多。
3.3 定时任务的必要性与实现
每天的健康打卡统计离不开定时任务。SpringBoot2自带@Scheduled注解，不需要引入额外的Quartz依赖就能实现：每天23:00扫描一遍全量学生，找出当天未打卡的人，生成待办消息推给对应辅导员。定时任务里最关键的坑是时区问题：服务器默认时区和北京时间不一致，导致Cron表达式触发的时刻不对。解决办法是在启动类或配置文件中指定时区，最简单的方式是配置项加上spring.jackson.time-zone=GMT+8，同时在定时任务中显式使用localDateTime.now()配合ZoneId指定国内时区。
实际开发中这个任务还会遇到性能问题：上万名学生一次性查出来循环比对，虽然MySQL8.0可以扛住，但更好的做法是定时任务里分批处理，每批500人，配合PageHelper或MyBatis-Plus的分页查询，避免一次性加载大量数据造成内存压力。
4. 前端落地：Vue3组合式API与后台管理界面
4.1 为什么这个阶段我强烈建议Vite而不是vue-cli
很多教程还在教vue-cli创建Vue3项目，但我建议新项目直接用Vite。核心原因就一个：快。Vite基于ESModule，开发环境下冷启动是秒级，热更新也是毫秒级响应。而vue-cli的Webpack方案，每改一行代码都要重新打包，开发体验差距太大。另外这个项目既然用了Vue3，搭配Vite是官方主推的路线，遇到问题社区解决方案也多。
创建项目的命令很简单：
npm create vite@latest epidemic-admin -- --template vue cd epidemic-admin npm install npm run dev4.2 组合式API是Vue3的核心分水岭
Vue3相比Vue2最大的变化就是组合式API，也就是setup语法。我在给学生讲的时候经常用一个类比：Vue2的Options API像把一份报告分成"背景"、"数据"、"方法"三个固定章节，一个功能的代码被拆散在不同区域；Vue3的Composition API则像按项目归档，每个功能的变量、方法、生命周期全放在一起。
实际编码中，健康打卡页面的逻辑大概长这样：
<script setup> import { ref, reactive, onMounted } from 'vue' import { submitHealthCheck, getTodayRecord } from '@/api/health' const todayRecord = ref(null) const form = reactive({ temperature: 36.5, cough: 0, fatigue: 0, contactRisk: 0 }) const loadToday = async () => { todayRecord.value = await getTodayRecord() } const submit = async () => { await submitHealthCheck(form) ElMessage.success('打卡成功') loadToday() } onMounted(loadToday) </script>表单校验是另一个Vue3的核心场景，比如体温必须填写且在35.5到42之间这个范围。Vue3里用Element Plus的rules配置很方便，但要注意一个细节：自定义校验函数必须执行callback，否则表单会一直卡在校验中状态。这是我踩过的坑，也见过不少新手栽在里面。
4.3 前端调用后端的接口协议与axios封装
前后端分离项目必须解决的第一个问题是接口对接。前端封装axios时，统一处理baseURL、token、响应拦截器。建议在src/utils/request.js里封装一个实例：
import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) config.headers.Authorization = `Bearer ${token}` return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { ElMessage.error('网络异常，请稍后重试') return Promise.reject(error) } ) export default request这里要注意跨域问题。本地开发最常见的方案是在Vite配置文件里配proxy代理，而不是在后端开CORS。后端的CORS配置如果放开所有域名，生产环境会引入风险，比如携带着用户token的请求可以被任意第三方网站发起。Vite proxy配置如下：
server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }前端所有请求都写在/api下面，代理自动转发到8080端口，浏览器看到的还是同源请求，绕开了跨域限制。
4.4 权限路由的实现思路
管理后台几乎必然需要权限控制：学生登录后看不到管理员的菜单和页面。Vue3实现路由守卫配合本地存储或Pinia状态管理能解决大部分需求。我建议的方案是：登录成功后将用户角色信息存入Pinia，在路由配置里用meta字段标记哪些路由需什么角色，router.beforeEach里做校验：
if (to.meta.role && to.meta.role !== store.user.role) { ElMessage.warning('无权访问该页面') return '/' }比把所有页面全部注册成静态路由再在页面里做按钮级控制要省事得多，菜单也能直接根据角色动态生成。
5. 数据库环境：MySQL8.0的安装配置与SQL细节
5.1 MySQL8.0值得注意的几个改变
MySQL8.0相比5.7，有几个对开发和部署影响明显的区别，我在第一次使用8.0时也踩过坑。
第一是默认认证插件变了。8.0起默认使用caching_sha2_password，而很多老工具或旧版驱动（尤其是一些图形化客户端和服务端程序）只支持mysql_native_password，导致连接时报错。解决办法：要么升级驱动连接器，要么在建用户时指定认证插件：
CREATE USER 'epidemic'@'%' IDENTIFIED WITH mysql_native_password BY 'yourpassword'; GRANT ALL PRIVILEGES ON epidemic.* TO 'epidemic'@'%'; FLUSH PRIVILEGES;第二是SQL关键字更敏感了。在8.0里，rank、window、groups这些都成了保留字，建表时字段名尽量避免这些词汇。疫情管理系统的表中，status、type这种字段名完全安全，但不要用rank做字段名。
第三是group by的行为更严格了。MySQL8.0默认开启ONLY_FULL_GROUP_BY，查询SELECT和GROUP BY的字段必须严格匹配。聚合查询时不要图省事直接select所有字段，而要明确指定分组字段，否则直接报错。
5.2 数据库初始化脚本的设计
源码自带的SQL脚本建议先完整过一遍，不要盲目执行。重点检查三件事：字符集是否统一为utf8mb4（否则emoji和生僻字会变成乱码）、是否存在外键约束导致表创建先后顺序问题（可以先创建全部表再加外键）、是否设置了合理的索引（用户表的college_id、打卡表的user_id+check_date都要建索引）。
我整理了一个建库模板供参考：
CREATE DATABASE IF NOT EXISTS epidemic DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE epidemic; DROP TABLE IF EXISTS user; CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '用户ID', username VARCHAR(50) NOT NULL COMMENT '账号', password VARCHAR(100) NOT NULL COMMENT '密码(MD5加盐)', real_name VARCHAR(30) NOT NULL COMMENT '姓名', role_type TINYINT NOT NULL COMMENT '角色:1-学生 2-教职工 3-管理员', college_id BIGINT COMMENT '学院ID', class_id BIGINT COMMENT '班级ID', dormitory_id BIGINT COMMENT '宿舍ID', phone VARCHAR(20) COMMENT '联系电话', status TINYINT DEFAULT 1 COMMENT '状态:1-正常 0-禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_college (college_id), KEY idx_class (class_id) ) ENGINE=InnoDB COMMENT='用户表'; DROP TABLE IF EXISTS health_check; CREATE TABLE health_check ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, check_date DATE NOT NULL, temperature DECIMAL(3,1) NOT NULL, cough TINYINT DEFAULT 0, fatigue TINYINT DEFAULT 0, contact_risk TINYINT DEFAULT 0, health_code TINYINT DEFAULT 1 COMMENT '1-绿码 2-黄码 3-红码', remark VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_date (user_id, check_date) ) ENGINE=InnoDB COMMENT='每日健康打卡';注意到create_time和update_time我用了DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP，这样插入和更新时不需要手动维护时间字段，省了很多样板代码。
5.3 Docker安装MySQL8.0的快速方式
如果本机不想直接安装MySQL，Docker是最省事的方案。一条命令就能拉起一个8.0实例：
docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=root123 \ -e TZ=Asia/Shanghai \ -v /opt/mysql-data:/var/lib/mysql \ mysql:8.0这里有两个参数值得说明。-e TZ=Asia/Shanghai是因为容器默认时区是UTC，SpringBoot连接后时间会偏移8小时。-v /opt/mysql-data是数据持久化，否则容器销毁后数据全丢，这在开发机上跑的时候最容易忽略。
6. 从源码到可演示项目：部署运行的全过程与常见问题排查
6.1 本地环境跑通的四个步骤
拿到源码后，我推荐按这个顺序操作，能规避九成以上的启动问题。
第一步是统一JDK版本。SpringBoot2要求JDK8及以上，我用的是JDK8或JDK11都没有问题。如果本机装了多个JDK，IDEA里Project Structure和Settings里都要确认用的是同一个版本，两处不一致会出现"错误: 无效的源发行版"。
第二步是配置MySQL账号信息。打开application.yml，确认数据库连接串、用户名、密码与本地一致：
spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/epidemic?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: root123serverTimezone=Asia/Shanghai和useSSL=false这两个参数尤其重要，前者避免日期写入数据库时出现8小时偏差，后者避免本机没有SSL证书时连接报错。allowPublicKeyRetrieval=true是配合MySQL8.0的caching_sha2_password认证方式用的，防止连接时报出public key retrieval not allowed的错。
第三步是执行数据库脚本。用Navicat或命令行执行项目doc目录下的init.sql。执行时如果遇到"Unknown database"之类的错误，先手动创建数据库或把脚本开头的CREATE DATABASE语句单独执行。
第四步是先启动后端再启动前端。后端启动看日志里出现"Started Application in X seconds"，说明接口层跑通了。前端npm run dev启动后，浏览器访问localhost:5173，能看到登录页就说明前后端已经连上了。用默认管理员账号登录后，第一件事是检查首页的统计数字是否能正常加载，这一步能确认数据库连接和第一张业务表的读写都正常。
6.2 最常见的启动失败问题排查
我在带学生跑这类项目时，总结出几个高频问题。
问题一：接口请求404。前端能打开登录页，但点击登录时请求报404。绝大多数情况是代理没配对，检查前端vite.config.ts里的proxy配置target是否真的指向了后端启动的端口。还有一种情况是后端项目没在8080端口启动，而是随机分配了一个端口。
问题二：MyBatis-Plus的Mapper扫描不到。SpringBoot启动时报"Invalid bound statement (not found)"。需要在启动类上加@MapperScan注解，或者用@Mapper注解标记每个Mapper接口。尤其注意如果Mapper接口和XML文件不在同一个包路径下，还需要在application.yml里指定XML文件的位置：
mybatis-plus: mapper-locations: classpath:mapper/*.xml问题三：数据库连接失败。报错信息若包含Access denied for user，检查密码或用户名是否打错；包含Unknown database则说明数据库还没创建；包含Communications link failure则大概率是MySQL服务没启动，Linux环境可以用service mysql status检查，Windows环境看任务管理器里的服务进程。
问题四：前端npm install失败。这类问题多半是镜像源访问慢导致的。切换成国内镜像源：
npm config set registry https://registry.npmmirror.com之后再重新install，成功率会提升非常多。
6.3 演示时的加分细节
这个项目最容易被评委关注的点有三个，建议演示前做好准备。
第一是权限控制的演示。分别用学生账号和管理员账号登录，展示同一个环境下不同角色看到的菜单差异，比只演示管理员账号更有说服力。
第二是异常流程的闭环演示。先模拟提交一次体温异常的打卡，去辅导员账号里查看待处理记录，处理成"确认异常"后，再去管理员端看到的状态变化和隔离记录。这个流程走通，说明系统不是简单的增删改查。
第三是统计报表的直观化。如果前端已经集成了ECharts，把首页的今日打卡率、各学院打卡率对比图展示出来。答辩时数据可视化页面永远是最抓眼球的部分。
7. 源码中"含文档"的价值：毕设文档比代码更值钱
7.1 文档里应该包含哪些核心内容
这个项目附带文档，这点对做毕业设计的同学来说非常关键。一套完整的毕设文档，我认为至少要覆盖这些内容：
需求分析部分：系统背景、用户角色、功能用例图、业务流程说明。这部分要能回答"为什么做这个系统"。
系统设计部分：总体架构图、功能模块划分、数据库ER图、核心表结构说明。这部分要能回答"系统怎么搭出来的"。
系统实现部分：每个模块的代码思路、核心类的职责说明、关键技术点的实现分析。这部分是硬货，直接展示工作量。
系统测试部分：测试用例表格、功能测试结果、性能测试简述。哪怕只做一轮简单的功能测试记录，也比缺失这部分有说服力。
7.2 文档与源码如何对照阅读
我见过太多学生拿到源码后一头扎进代码里，结果看三天还是一头雾水。更高效的方式是"文档先行"：先读需求分析里的功能列表，再对照数据库表结构，搞清楚每张表对应哪个功能模块；然后顺着一条业务链路走一遍代码，比如登录-首页-打卡-提交，把这几个接口的Controller、Service、Mapper全部跟一遍，项目的整体脉络就清楚了。
顺带说一个拆解技巧：在IDEA里按Ctrl+Shift+F全局搜索关键词，比如搜索"health_check"能快速定位到所有操作这张表的代码；搜索"accessApply"能定位到出入校申请的相关代码。这比手动翻目录高效得多。
8. 项目还能怎么扩展：几个值得尝试的方向
如果不想止步于"跑通一个毕业设计"，这套系统还有几个不错的扩展角度，能显著增加项目的完整度和技术含金量。
接入消息通知。目前系统里审批和异常通知基本靠站内消息，扩展方向是接入邮件或短信服务，学生提交出校申请后，辅导员实时收到通知。SpringBoot里集成JavaMail或者阿里云短信都不复杂，费用也很低。
增加数据可视化大屏。在管理端首页接入ECharts，展示今日打卡率、各学院对比、近7天体温异常趋势。这部分代码量不大，但视觉效果提升非常明显。
引入Redis缓存。健康打卡的当日记录是高频读取数据，把当日统计结果缓存到Redis，设置过期时间到第二天凌晨，能显著降低数据库压力。把这一步做掉，系统架构就多了一个"缓存层"，答辩时能讲的技术深度完全不一样。
我在实际使用中发现，这类项目最大的敌人不是技术难点，而是需求梳理不清导致代码反复修改。功能边界没定好就急着写SQL建表，后面改起来非常痛苦。建议动手之前先把用户角色和核心流程在纸上画清楚，建表顺序按"用户-业务-流程-统计"逐层推进，每一步都明确依赖关系，后期的返工成本会小很多。
最后再分享一个对新手价值很高的小技巧：在本地跑通项目之后，找一条最核心的业务链路（比如学生打卡到辅导员审核的完整过程），从头到尾读一遍对应代码，然后在代码里打上详细的注释，拿这套代码去讲给同学听。能把别人讲明白，说明你离真正掌握这套系统就不远了。
