SpringBoot+Vue疫情隔离管理系统完整毕设项目：从数据库到前后端联调全解析

毕业设计季很多人在找项目源码但我见过太多下载下来跑不起来的SpringBootVue项目了。要么缺SQL脚本要么接口文档不完整要么前端页面和后端接口对不上。今天分享的这套疫情隔离管理系统是一套完整可运行的Java Web毕设项目从数据库脚本到后端接口再到前端页面全都齐了。我会从业务流程梳理、表结构设计、接口实现、前端联调一直讲到答辩前的检查清单把整个项目从头到尾拆开给你看。先说清楚这套系统是干什么的在特定时期社区、学校或单位需要对相关人员进行隔离观察管理人员需要登记人员信息、安排房间、记录每日健康状况、跟踪隔离周期。疫情隔离管理系统就是把这一整套线下的登记和跟踪工作线上化。整个项目采用SpringBootVue的前后端分离架构后端提供RESTful接口前端用Vue独立开发数据库使用MySQL配套SQL脚本和Knife4j接口文档非常适合作为Java Web方向的毕业设计项目。1. 隔离管理这种业务为什么适合做成前后端分离的毕设很多同学选毕设题目时容易走两个极端要么是图书管理系统这种做了无数遍的题目答辩老师一看就没兴趣要么是电商秒杀、高并发抢购这类根本不现实的题目造一堆假需求。疫情隔离管理系统恰好卡在一个很舒服的位置——业务足够具体逻辑适中前后端该有的技术点全都覆盖又不至于复杂到无法完成。1.1 角色、流程和数据流转先搞清隔离管理在管什么做项目最忌讳上来就打开IDE写代码。我建议你先花半天把业务理清楚因为后面所有的表设计、接口划分、前端页面都是从业务流程推导出来的。隔离管理系统涉及的参与角色主要有三类系统管理员维护系统基础数据创建工作人员账号查看全局隔离情况工作人员/医护人员登记隔离人员、分配房间、录入每日健康监测数据、审核解除隔离申请隔离人员通过工作人员代录或自助填报的方式提交每日体温和健康状况核心业务流程是隔离人员登记→安排隔离房间→进入隔离周期→每日健康数据上报→隔离期满审核→解除隔离数据层面就是围绕这个流程走的。登记时产生人员基础信息分配房间时产生隔离记录每日上报产生健康监测记录期满审核更新隔离状态。理解了这条线后面设计数据库时你自然知道该建哪些表。这个业务还有一个好处存在明确的状态流转。隔离状态从隔离中到待解除再到已解除这决定了界面上需要根据状态显示不同操作按钮后端需要根据状态校验操作合法性这些细节在答辩时都是可以展开讲的东西。1.2 SpringBootVue组合为什么是毕设的稳妥选择从能跑起来、能讲清楚、能过答辩这三个目标出发SpringBootVue是目前Java Web毕设里性价比最高的组合。SpringBoot解决了传统SSM项目里大量XML配置的问题内置Tomcat打成一个jar包就能跑部署非常省心。对于毕设来说你不需要在环境搭建上耗费一个月可以把时间花在业务功能上。而且SpringBoot在企业里的使用率极高这个技术选型本身就符合就业市场需求答辩老师认可度也高。Vue作为前端框架上手曲线比React平缓中文资料极其丰富。更重要的是Vue支持组件化开发你可以把侧边栏、表格、表单弹窗这些公共部分抽成组件页面之间复用代码量可控。配合Element UI组件库不需要专门的前端功底就能做出还不错的界面。还有个加分项是前后端分离架构本身。答辩时你可以讲清楚前后端如何通过JSON交互、如何处理跨域、如何用JWT做无状态登录这些都属于面试常问的加分点。当然前后端分离也意味着你要处理联调问题比如跨域配置、接口约定、token传递这些坑我后面会逐个说。2. 数据库设计从业务流程推导表结构而不是上来就写SQL数据库是一套系统的地基。我拿到项目源码时首先看的就是SQL脚本。这几个表的设计基本能反映作者有没有真正理解隔离管理业务。数据库设计这块我准备详细说说因为大部分毕设项目最薄弱的环节恰恰是这里。2.1 核心表结构与字段设计整套系统的核心表可以拆成人员相关隔离业务相关系统支撑相关三组。人员相关包含系统用户表和隔离人员表。系统用户表存管理员和工作人员的登录账号字段包括用户名、密码、真实姓名、角色类型、手机号等。这里有个细节密码字段不要用明文存储项目里用了MD5加盐处理虽然MD5现在看不算安全但作为毕设演示已经够用答辩时能说明为什么不用明文存密码这个意识就是加分项。隔离人员表保存隔离者本人的台账信息姓名、身份证号、性别、联系电话、来源地、现住址、健康状况、隔离状态、登记时间、登记工作人员ID等。隔离状态这个字段很关键它贯穿整个业务流程项目里用tinyint类型存储0表示待隔离1表示隔离中2表示已解除。用数字存状态而不是直接用字符串好处是接口返回、前端判断、SQL统计都比较高效。隔离业务相关的表包括隔离记录表、健康监测表和解除隔离申请表。隔离记录表记录一次完整的隔离过程字段有隔离人员ID、房间号、隔离开始时间、预计解除时间、实际解除时间、负责工作人员ID、状态和备注。这张表是主业务表关联查询最多建立索引时优先考虑隔离人员ID和状态字段。健康监测表记录隔离期间每日上报的数据包括隔离记录ID、体温、是否咳嗽、是否乏力、监测日期、上报时间、上报人类型等。一张隔离记录会对应多条监测记录这是典型的父子表关系。解除隔离申请表则记录隔离人员提交解除申请的时间和当前审批状态审批通过后更新隔离记录表中的实际解除时间同时把隔离人员表的状态改成已解除。系统支撑相关主要就是菜单权限表和操作日志表。菜单权限表做动态路由菜单操作日志表记录关键操作的增删改痕迹比如谁在什么时候登记了一个隔离人员、谁审批了解除申请。下面把核心表结构汇总一下表名用途主要字段关联关系sys_user登录用户id, username, password, real_name, role, phone与隔离人员表通过register_id关联person_info隔离人员台账id, name, id_card, phone, source, address, status与隔离记录表一对多isolation_record隔离记录id, person_id, room_no, start_time, end_time, actual_end_time, status与健康监测表一对多health_monitor健康监测id, record_id, temperature, cough, fatigue, monitor_date从属于isolation_recordrelease_apply解除隔离申请id, record_id, apply_time, apply_reason, audit_status从属于isolation_recordsys_log操作日志id, user_id, operation, create_time与sys_user关联2.2 SQL脚本中的字符集、时间字段和初始化数据SQL脚本看起来简单但几个细节处理不好导入就会报错或者出现中文乱码。我直接说这个项目脚本的关键点。数据库和表的字符集统一用utf8mb4不要只写utf8。utf8mb4是utf8的超集能正常存储emoji和生僻字MySQL 8.0默认就是utf8mb4。如果建表时统一加上DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci后面导入数据时基本不会出幺蛾子。时间字段的选择也要注意。隔离开始时间、预计解除时间、实际解除时间这些都用datetime类型不要用timestamp。timestamp从1970年开始算起2038年会溢出虽然毕设项目不会真跑到2038年但datetime能存的范围更宽、读取出来就是正常的日期格式对前端展示更友好。更重要的是涉及预计解除时间这种需要前端做倒计时或日期计算的地方datetime类型在用MyBatis映射时不容易出现时区偏移问题。初始化数据这块项目里预置了一个管理员账号admin和一个工作人员账号staff密码都是加密后写入的。初次导入SQL后直接就可以用这两个账号登录这个细节对评审老师演示很友好。隔离人员数据和健康监测数据也预置了几十条时间范围设置得比较接近当前日期这样首页的统计图表打开就有数据看。初始化数据的时间如何编排很多同学不注意但偏偏这个是演示环节最容易露怯的地方。如果SQL脚本里的隔离开始时间写的是2022年而你答辩是2025年一打开页面隔离中的人员早就超期了看起来很假。好的做法是SQL脚本里用相对日期的写法比如DATE_SUB(NOW(), INTERVAL 3 DAY)表示三天前隔离DATE_ADD(NOW(), INTERVAL 4 DAY)表示四天后预计解除这样无论什么时候导入数据演示画面都是真实的。2.3 外键和索引的取舍收到很多私信问要不要建外键。我的建议是这个项目里主业务表之间不要用物理外键用逻辑外键就够了。物理外键的问题在于插入数据必须严格遵循父表先存在删除数据时必须先处理子表批量导入测试数据时会非常痛苦。而且一旦线上环境数据量上来外键约束对写入性能有影响。项目里所有表只有主键和普通索引表之间的关联关系通过业务代码来保证比如删除一个隔离人员之前先删除他名下的隔离记录和健康监测记录用事务控制。答辩时被问到为什么不用外键你就回答用逻辑外键保证灵活性和性能用事务保证数据一致性这个答案无论是开发规范还是面试角度都是站得住的。索引方面person_info表的id_card加唯一索引isolation_record表的person_id加普通索引health_monitor表的record_id加普通索引sys_log表的create_time加普通索引。这些索引都是基于查询场景建立的答辩时可以顺势讲出这条索引是为了支撑哪个查询。3. 后端接口RESTful规范、JWT鉴权与Knife4j文档的实际落地看完了数据库接下来是后端。这套项目后端用SpringBoot 2.7版本MyBatis-Plus做持久层JWT做无状态登录Knife4j生成接口文档。我一个个说这些技术点在这个项目里是怎么落地的。3.1 后端分层结构与核心依赖先看工程结构。项目采用标准的controller、service、mapper三层架构外加config、common、entity、dto这几个包。controller只负责接收参数和返回结果service写业务逻辑mapper负责数据访问。entity映射数据库表dto作为接口入参和出参对象避免直接把实体类暴露给前端。有一个点值得说一下就是接口返回的统一格式。项目里所有接口返回的都是一个统一的结构体包含code、message和data三个字段。code为200表示成功401表示未登录或token失效500表示业务异常。这样做的好处是前端axios拦截器只需要判断code就可以统一处理所有接口的异常情况不需要每个页面都写一遍try-catch。这个设计在面试中说出去也是加分项。依赖方面pom.xml里需要重点关注这几项dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.2.1/version /dependency dependency groupIdcom.github.xiaoymin/groupId artifactIdknife4j-spring-boot-starter/artifactId version3.0.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependencySpringBoot的版本和MyBatis-Plus的版本要注意兼容。如果SpringBoot用了3.xMyBatis-Plus用2.x大概率会出问题。项目里我实测SpringBoot 2.7.x搭配MyBatis-Plus 3.5.x是比较稳定的组合不要盲目追求新版本。3.2 JWT鉴权和跨域配置前后端分离的关键一环前后端分离架构下后端接口默认是不允许跨域调用的登录状态也不能依赖Session这时候JWT就派上用场了。JWT的机制我用大白话解释一下用户登录成功后后端生成一个加密的token字符串返回给前端前端把token存在localStorage里之后每次请求都在请求头里带上这个token后端拦截器验证token合法后放行。因为token本身包含用户ID和过期时间所以后端不需要在服务器内存里保存会话状态这就是无状态登录。项目里JWT的配置集中在JwtUtil和JwtInterceptor两个类里。生成token时会设置过期时间一般设置7天这个时长对毕设演示来说是够用的。拦截器排除登录接口、验证码接口和Knife4j文档相关路径其余接口全部拦截验证。这里有个容易踩的坑拦截器排除路径的写法要准确否则会导致登录接口也被拦截或者静态资源加载不出来的问题。跨域配置这块项目里用WebMvcConfigurer实现了一个CorsConfig类允许前端地址http://localhost:8080跨域访问后端http://localhost:9090。注意allowCredentials要设为trueallowedHeaders用*的话有时会因为携带Authorization头而报CORS错误更稳妥的做法是显式允许Authorization头。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有一个非常值得注意的坑如果同时使用了Spring Security或者自定义拦截器跨域配置和拦截器的执行顺序一定要理清楚。CORS的处理优先级应该高于登录拦截否则前端请求在预检阶段就被拦截器挡住了表现为跨域报错实际却是拦截器没有放行OPTIONS请求。这个项目里没有引入Spring Security只用JWT拦截器所以情况简单很多但你要知道这个机制答辩时被追问能说清楚。3.3 Knife4j接口文档写文档也是答辩得分点接口文档这块项目直接集成了Knife4j。相比原生的Swagger UIKnife4j的界面更符合国内开发者的使用习惯接口分组、参数说明、在线调试都做得更清晰。在浏览器里访问后端的/doc.html路径就能打开文档页面。为什么要在毕设里集成接口文档两个原因。第一接口文档是前后端联调的基础前端同学看着文档就知道该调哪个接口、传什么参数。这套项目虽然是你一个人做但接口文档能帮你理清接口逻辑写文档的过程本身就是对接口设计的一次复盘。第二答辩时打开Knife4j的文档页面几十个带分组、带参数说明、带返回示例的接口整整齐齐列出来老师一下就知道你的项目是完整工程化的不是拼凑的demo。每个接口的注释要认真写Api注解标记接口分组和用途ApiOperation描述接口含义ApiImplicitParam说明每个入参。这些注解不会影响代码逻辑但对文档生成来说至关重要。项目里包括登录、隔离人员管理、隔离记录管理、健康监测管理、解除隔离申请、统计报表六组接口主流程接口都做了完整的参数说明和返回示例。实际写后端接口时需要注意一个细节日期类型在JSON序列化时的格式问题。Java里的LocalDateTime默认序列化出来的格式是2025-01-15T10:30:00中间带字母T前端展示时很丑。项目里通过Jackson的配置统一将LocalDateTime格式化为yyyy-MM-dd HH:mm:ss前端拿到直接就能展示。4. 前端Vue页面规划、axios封装和前后端联调的三类高频坑后端接口都通了之后前端这边就是页面的堆叠和接口的对接。这套项目的前端用Vue 2 Element UI Axios ECharts页面风格走的是典型的管理后台路线。4.1 Vue项目目录与页面路由规划前端项目的src目录按这样的结构组织src/ api/ // 接口定义按模块拆分文件 assets/ // 静态资源 components/ // 公共组件 router/ // 路由配置 store/ // Vuex状态管理 utils/ // 工具函数 views/ // 页面组件页面侧的规划分为布局页和业务页两层。布局页负责整体框架包含左侧菜单、顶部用户信息栏、中间内容区套用路由的嵌套结构。业务页包括登录页、首页、隔离人员管理页、隔离记录页、健康监测页、解除隔离申请页、系统日志页和统计分析页。路由配置里有一个关键点路由守卫。项目里通过路由守卫实现未登录不能访问任何页面的逻辑。具体做法是在router.beforeEach里判断localStorage里有没有token没有就跳转到登录页。同时用Vuex保存当前用户的基本信息登录成功后拉取一次用户详情存起来侧边栏显示用户名、头像这些都要用到。这一步解决了前端页面层面的权限控制问题和后端的JWT拦截形成双重保障。4.2 axios封装统一处理token、错误码和401跳转前端调接口如果每个页面都写一遍axios代码会非常冗余。项目里把axios实例封装在utils/request.js里统一做了三件事请求拦截器把token从localStorage取出来加到请求头响应拦截器根据后端返回的code统一处理遇到401就清除本地登录信息并跳回登录页。// utils/request.js import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: process.env.VUE_APP_BASE_URL, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } Message.error(网络异常请稍后重试) return Promise.reject(error) } ) export default service接口定义按模块拆成api/user.js、api/isolation.js、api/health.js、api/release.js等文件每个文件导出一个包含多个接口方法的对象。比如隔离记录接口import request from /utils/request export function getIsolationList(params) { return request({ url: /isolation-record/page, method: get, params }) } export function createIsolationRecord(data) { return request({ url: /isolation-record, method: post, data }) }这样封装的好处是页面里引用起来非常简洁而且改动接口地址只需要在api文件里改不需要全局搜索。页面里调用时返回的是一个Promise用async/await拿数据代码可读性也更高。4.3 联调中最高频的三个坑与排查方式前后端联调是整个项目里花费时间最多、也最容易让人崩溃的环节。我把这套项目联调过程中最常见的三类问题单独拎出来说你照着排查能省半天时间。第一个坑是跨域报错。表现是浏览器控制台出现CORS或者Access-Control-Allow-Origin相关的红色报错。前端的排查思路是先确认后端项目的CorsConfig是否已经放开跨域然后确认前端请求的baseURL是不是指向了后端地址。有时你把前端跑在8080端口、后端跑在9090端口默认就是不同源必须靠后端CORS配置配合才能通过浏览器的同源策略。一个很隐蔽的问题如果前端设置的baseURL写错了比如少写了一个/请求打到后端不存在的路径上返回404浏览器有时也会提示跨域报错所以第一个判断依据应该是Network面板里看请求是否真的发到了后端。第二个坑是参数接收不到。前端传入的参数后端取不到值多半是请求方式不匹配。GET请求用params传参后端用RequestParam接收POST请求用data传JSON后端要用RequestBody实体类接收。把这两组对应关系搞错最常见的表现就是后端接口能调到但参数全是null。这个在排查时先看Network面板的请求Payload确认前端是query参数还是request body再对照后端的注解问题基本立刻就能定位。第三个坑是刷新页面后404。前端用vue-router的history模式时刷新一个子路由页面比如/isolation/listTomcat和SpringBoot的默认配置找不到对应的后端路由就会返回404。解决办法有两种一是改用hash模式URL里带#号刷新不会出问题二是在后端配置一个路由转发把前端所有路由都转发到index.html。这个项目里用hash模式简单不容易出问题。如果你对URL美观度有要求可以尝试history模式但一定要配置好转发规则否则刷新404这个坑会让你排查很久。关于ECharts图表项目首页和统计页用了柱状图、折线图和饼图展示隔离人员分布、每日新增隔离人数、隔离状态占比。图表数据来自后端的统计接口返回的数据结构是名称值的数组格式ECharts直接绑定就能渲染。需要注意的一个点是图表容器必须有确定的宽度和高度否则初始化后看不到图。有些同学把图表放在tab页切换里一开始隐藏的tab渲染图表时容器宽度为0图表就不显示解决思路是在tab切换完成后调用图表的resize方法。5. 跑通整套源码环境安装、启动顺序与毕设演示前的自检清单最后这部分是实战落地环节。很多同学下载了源码却跑不起来问题往往出在环境版本不匹配或者启动顺序不对。我给你梳理一套从零到一跑通这个项目的完整流程。5.1 从安装环境到启动后端先确认你本地的环境版本这套项目实测可用的环境组合是JDK 1.8、Maven 3.6、MySQL 5.7或8.0、Node.js 14以上。版本差异是最大的隐形杀手JDK版本过高可能连不上低版本MySQL驱动Node版本过旧运行Vue项目会报语法错误。第一步创建数据库。打开Navicat或者命令行新建一个数据库取名为isolation_manage字符集选utf8mb4。然后导入项目里的SQL脚本。注意导入前一定要先选中数据库再执行脚本否则表会建到你默认的数据库里。第二步修改后端配置文件。在application.yml里把数据库的连接地址、用户名、密码改成你自己本地的配置。尤其注意时区参数serverTimezone国内一般设置为Asia/Shanghai或者GMT%2B8。如果不设时区连接MySQL 8.0时可能会报时区相关的错误这个报错信息挺典型的看到Server returns invalid timezone基本就是时区没配。第三步使用IDEA打开后端项目等待Maven自动下载依赖。如果下载慢可以换成阿里的Maven镜像。依赖下载完成后找到主启动类右键运行。看到SpringBoot启动成功的日志说明后端服务已经跑起来了默认端口是9090。5.2 启动前端并完成联调先用命令行进入前端项目的根目录执行npm install安装依赖。如果这个步骤报错绝大多数情况是网络问题可以换成淘宝的npm镜像源执行npm config set registry https://registry.npmmirror.com然后再试一次。依赖装好后接着就要核对前端配置文件里的后端地址。项目里前端根目录有一个.env.development文件里面配置了VUE_APP_BASE_URL要确保这个值指向你后端实际运行的地址。比如后端跑在9090端口这里就写http://localhost:9090。最后执行npm run serve等Vite或者Webpack编译完成终端会显示一个本地访问地址一般是http://localhost:8080。浏览器打开这个地址就能看到登录页面了。用预置的管理员账号admin登录如果能看到首页的统计面板说明前后端联调成功。5.3 答辩演示前的检查清单与高频面试追问项目跑通之后离答辩还有最后一公里。我把演示环节最容易翻车的点整理成清单你可以照着检查一遍。演示数据方面确认SQL脚本里的隔离记录日期是相对当前日期生成的这样页面显示的隔离中人员不会出现已经过期的情况。确认首页统计图表的数值是否合理比如隔离总人数和明细列表的数据要能对上老师如果随手点进列表核对数据对不上会很尴尬。演示路径方面建议走一遍完整的业务流程登录→登记一个隔离人员→给这个人分配房间→录入一条健康监测记录→提交解除隔离申请→管理员审批通过。把这条链路流程走通业务闭环就成立了。最好在答辩前把这条链路演练三遍以上确保点击的每个按钮都不会报500错误。高频追问方面评委老师可能会问这几个问题JWT的token过期了怎么办MyBatis-Plus和MyBatis有什么区别前端路由守卫和后端拦截器都能做权限控制为什么需要两层隔离满7天怎么自动判断前两个问题你按实际使用的机制回答就行。关于权限控制正确的理解是前端是体验层面的控制防止用户看到无权访问的页面后端是安全层面的控制防止绕过前端直接调接口。关于隔离时长判断后端在查询隔离中列表时会对比预计解除时间和当前时间超过预计时间就标记为待解除这里的计算逻辑要能讲清楚。还有一个小细节可以增加好感演示时顺便展示一下Knife4j接口文档页面挑一个接口现场调试。这个动作虽然简单但能证明接口文档不是摆设项目是真实可调试的老师对这个印象分会很高。最后我实际用的过程里还有一个感触想分享因为这套系统需要频繁联调我把接口地址和后端路径的映射关系整理成了一页纸贴在显示器旁边。后面调接口时基本不用翻代码一眼就知道哪个功能对应哪个URL。这个习惯我后来做其他项目也一直在用尤其是接口数量超过二十个之后一份简单的接口自查表能帮你在联调和答辩时节省大量时间。