SpringBoot+Vue3前后端分离管理系统实战：疫情隔离系统搭建与扩展

疫情隔离管理系统这名字听着挺应景，实际就是一套非常标准的Java Web前后端分离业务系统。整套源码我仔细拆过，SpringBoot2做后端接口、Vue3做管理界面、MyBatis-Plus简化数据层操作、MySQL8.0做底层存储，这套组合放在今天的中小型管理系统项目里属于绝对的主流配置。不管你是毕业设计要凑一套完整项目，还是刚学完SpringBoot和Vue想找个能跑通全流程的实战案例，这套隔离管理系统都值得好好拆一拆——它麻雀虽小，但用户权限、健康监测、房间分配、数据统计这些模块一应俱全，基本覆盖了一个业务管理系统从设计到落地的所有关键环节。

1. 系统需求拆解与整体方案设计

1.1 疫情隔离管理系统到底管什么

很多人看到"隔离管理"第一反应是搞一套复杂的物联网硬件对接，实际上绝大多数高校毕业设计和中小型项目的需求远没到那一步。这套系统的核心业务围绕"隔离人员从进入隔离点到解除隔离"的完整周期展开，主要管四件事：人、房、健康记录、出入行为。

人指的是隔离人员信息，包括基础身份信息、来源地、隔离原因、预计隔离周期；房指的是隔离点内的房间资源，需要实时知道哪些房间空闲、哪些有人占用、每个隔离点的入住率；健康记录是每天必须采集的体温、症状、核酸结果；出入行为则是隔离期间的外出申请、审批和门岗登记。剥掉所有花哨功能，这套系统的本质就是一套带状态流转的资源管理平台——人分配房、人产生健康数据、人触发出入行为，所有业务都围着这几张表转。

1.2 这套技术栈组合的选型逻辑

SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0这个组合非常有意思，它不是最强的，但绝对是最适合教学、毕设和中小型项目的。SpringBoot2选择的原因很实在：市面上绝大多数的教程、博客、开源脚手架还是以2.x为主，它本身足够稳定，同时SpringBoot3的底层是Spring6、JDK17起步，对很多还在用JDK8的同学不友好，学习成本和迁移成本都高。Vue3选得聪明，Composition API写起来比Options API更灵活，配合Vite构建速度极快，更重要的是Vue3的生态早两年可能还让人犹豫，现在Element Plus、Pinia、Vue Router都成熟了，完全可以直接上手。

MyBatis-Plus属于那种"用过就回不去"的增强框架，核心价值是CRUD不用自己写SQL了，单表操作用LambdaQueryWrapper几行代码就能搞定，分页插件也是现成的。至于MySQL8.0，相比5.7最明显的提升是支持窗口函数、默认字符集就是utf8mb4，对中文和表情符号的支持非常友好，而且现在新装的环境基本都是8.x起步，没有必要刻意去装老版本。

1.3 前后端分离架构的边界划分

这套系统采用标准的前后端分离：前端跑在Vite开发服务器上，端口5173左右，负责页面渲染、交互逻辑、路由控制；后端跑在SpringBoot内嵌的Tomcat上，默认8080端口，只暴露JSON接口。前后端之间的数据交互全部走HTTP请求，前端通过Axios发请求，后端通过RestController返回统一结果集。

这种架构最大的好处是职责边界非常清晰。前端只关心数据长什么样、展示什么状态；后端只关心业务规则、数据校验、状态流转。比如"申请解除隔离"这个动作，前端做的就是弹出一个提交按钮，把申请理由和佐证材料上传；后端要做的是验证当前隔离天数是否满足最低隔离期限、审批人权限是否足够、状态机是否允许从"隔离中"跳到"待解除"。边界一旦划清楚，前后端可以并行开发，出问题也容易定位。

2. 核心功能模块与数据库设计

2.1 角色权限模型的设计思路

权限模型是这类管理系统的地基，设计得不好后面加任何功能都会束手束脚。这套系统的用户角色分为四种：系统管理员、隔离点管理员、医护人员、隔离人员。隔离人员登录后看的是自己的健康上报、解除申请、房间信息；医护人员管理自己负责的隔离人员的每日健康数据；隔离点管理员看的是整个点位的房间资源和人员动态；系统管理员则统筹全局，管理用户、配置基础数据。

权限控制不推荐在业务代码里写死角色判断，最好走"角色-菜单-操作"的RBAC模型。后端在登录的时候把当前用户的角色和权限列表查出来，前端拿到之后动态渲染菜单和按钮——没有"审批"权限的人压根看不到审批入口，后端接口再校验一次，双保险。这套系统把这种模型落地得比较彻底，值得学习的点就在这：自定义注解加拦截器做权限校验，比手写一堆if-else要优雅得多。

2.2 核心数据表的结构要点

数据库设计直接决定这套系统能承载多少业务量。核心表大致有这几张：用户表、隔离点表、房间表、隔离人员登记表、健康监测记录表、出入登记表、审批记录表。其中房间表和隔离人员表的关系要特别注意，隔离人员进入隔离点时要分配房间，但在分配之前系统要校验房间状态必须是"空闲"，分配之后房间状态改成"占用"，这涉及事务和并发控制，不能只靠前端判断。

字段设计上有两个容易忽略的坑。第一是时间字段尽量用datetime而不是timestamp，前者范围更宽，而且MySQL8.0对datetime类型有毫秒精度的支持，做统计报表时更好处理。第二是预留一些冗余字段，比如健康监测表里冗余隔离人员的姓名和房间号，虽然违背了严格的三范式，但查询时的效率和便利性提升非常明显——管理端天天要做的就是按楼层、按房间拉健康记录报表，连表查询的代价完全没必要。

2.3 接口设计与统一返回体

前后端分离项目里，接口规范是联调效率的保障。这套系统采用REST风格设计接口，比如隔离人员的健康记录就是GET /api/health-records、POST /api/health-records，用资源名词加HTTP动词来表达操作语义。所有接口统一返回一个Result对象，包含code、message、data三个字段，code为200表示成功，401表示未认证，403表示无权限，500表示服务器错误。

统一返回体的好处是前端Axios拦截器里只需要对code做一次判断，不用为了每个接口单独写错误处理。如果后端直接抛异常，全局异常处理器会把异常转成统一的Result格式返回，前端拿到的永远是一个结构完整的响应体。这也是我认为这套系统里最有工程价值的设计之一——很多新手项目接口返回格式五花八门，前端每接一个接口就要适配一次，维护成本高到崩溃。

3. 实操过程：从零跑通这套系统

3.1 前端Vue3工程的搭建与改造

拿到源码后前端部分用Vite构建，Node版本建议16以上。先执行npm install把依赖拉下来，默认的依赖集中在package.json里，几个关键依赖是Vue3.4、Vue Router4、Pinia、Element Plus、Axios和ECharts。装完之后npm run dev启动开发服务器，浏览器访问本地端口就能看到登录页。

真正需要花时间看的是src目录下的几个核心文件：main.js里注册了Element Plus和Pinia；router/index.js里配置了路由守卫，判断未登录时跳到登录页；store目录下的user.js管理当前用户的token和基本信息；utils/request.js封装了Axios实例，请求拦截器把token塞进请求头，响应拦截器对Result的code做统一处理。新手改这套前端时最容易踩的坑是路由守卫和动态菜单配合不好——菜单是根据角色权限动态生成的，刷新页面时Pinia里的用户信息丢了，需要重新拉取用户信息后再生成菜单，不然刷新就白屏。

3.2 后端SpringBoot2工程的结构与配置

后端工程是标准的Maven结构。application.yml里最关键的是数据源配置，因为MySQL8.0的驱动类和之前不大一样，用的是com.mysql.cj.jdbc.Driver，同时必须加serverTimezone=Asia/Shanghai参数，不然日期字段会差8个小时。下面的配置片段可以直接抄走：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/isolation_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 你的密码
    driver-class-name: com.mysql.cj.jdbc.Driver
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 20MB

登录认证这块如果用的是Sa-Token或者Shiro应该都行，但如果是自己写的JWT拦截器，要重点检查拦截器是不是把所有接口都拦了。通常需要放行登录、验证码、静态资源这几个路径，否则前端怎么都登不进去。后端包的划分我建议按controller、service、mapper、entity、common、config这几层走，拿到源码后先别急着改业务，把这个分层结构看明白再说。

3.3 MyBatis-Plus整合的四个关键点

MyBatis-Plus使用的关键点总结起来就四个：主键策略、自动填充、分页插件、条件构造器。

主键策略推荐用ASSIGN_ID（雪花ID），不要用数据库自增，这样在分布式环境下不会有主键冲突。自动填充是针对createTime和updateTime这类字段的，配置一个MetaObjectHandler，插入和更新的时候自动填值，不用每次手动set。

分页插件必须要配置，这是很多新手漏掉的一步。只有把PaginationInnerInterceptor注册到MyBatis-Plus的拦截器链里，分页查询才会生效，否则分页参数全被忽略，查出来的是全量数据。

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

条件构造器LambdaQueryWrapper是日常用的最多的工具，比如按隔离状态筛选人员，代码就是：

java复制LambdaQueryWrapper<IsolationPerson> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(IsolationPerson::getStatus, "隔离中")
       .like(StringUtils.isNotBlank(keyword), IsolationPerson::getName, keyword);

这种写法能避免把字符串拼进SQL导致注入风险，类型安全也更好。

3.4 MySQL8.0环境准备与数据初始化

数据库这块，新装的MySQL8.0有两个坑必须注意：一是认证插件默认是caching_sha2_password，老版本的Navicat、JDBC驱动可能连不上，解决方法是换配置或者修改用户认证插件；二是MySQL8.0默认字符集已经是utf8mb4，建库时不需要再纠结字符集问题。

初始化数据一般是导入项目里自带的isolation_db.sql文件，里面除了表结构还带了初始账号数据。导入时用命令行source或直接用DBeaver执行SQL文件都行。如果导入报错提示表已存在，说明库名建错了，务必先确认自己连的是不是isolation_db这个库。另外建议顺手设置一下MySQL8.0的其他参数，比如max_allowed_packet改大一点，否则导入大SQL文件时容易中断。

4. 常见问题与排查技巧实录

4.1 环境阶段的高频坑

能让人卡住一整天的往往不是业务逻辑，而是环境问题。MySQL8.0的连接问题排在首位，报错一般是Public Key Retrieval is not allowed或者Unable to load authentication plugin。前者在JDBC URL后面加allowPublicKeyRetrieval=true就能解决，后者多半是因为驱动版本低于5.1.49，必须升级到8.x版本的驱动。还有端口占用，SpringBoot默认8080，如果你本机装了多个服务占了端口，启动日志会直接告诉你端口被占用，改一下server.port或者干掉占用进程就行。

前端这边报错最频繁的是Node版本不兼容，Vite3以上的版本要求Node16起步，用12的老版本会提示require is not defined之类的错误。装依赖时如果报ERESOLVE错误，一般是npm版本和依赖树解析策略的问题，用npm install --legacy-peer-deps可以绕过去。

4.2 前后端联调时的典型问题

联调阶段最常见的就是跨域。前端跑在5173端口，后端跑在8080端口，浏览器同源策略会对跨域请求做拦截。解决跨域有几招，开发环境最省事的是后端加一个CORS配置类，允许所有域名跨域访问。但这里要注意，允许所有域名跨域只适合开发环境，如果部署上线，必须改成只允许你实际的前端域名。

另一个典型问题是Axios请求后端的PUT、DELETE请求返回404。排查思路很简单：先看后端Controller上有没有加对应的方法注解，再检查前端提交的请求路径是不是和后端的RequestMapping对得上。这类问题九成都是路径拼错或者请求方法用错了，先用浏览器的Network面板确认实际发出的请求URL和方法，再回到后端代码对照。

4.3 部署环节的注意事项

打包时前端需要改两个地方：一是请求后端的baseURL，开发时走的是http://localhost:8080，部署时要改成你服务器上后端的实际地址；二是前端打包产物要放在Nginx的静态文件目录里。后端打包用Maven的package命令，会打成可执行jar包，用java -jar直接启动。

一个容易被忽略的问题是后端的配置文件里可能有本机绝对路径，比如文件上传的存储路径。部署之前建议把这类路径改成相对路径，或者用配置项读出来，不然换个环境就要改一次代码重新打包。前端部署到Nginx之后还要配一下try_files，把路由重写到index.html，否则前端路由用history模式时，刷新一个非首页的地址会报404。

4.4 常见问题速查表

5. 这套系统还能怎么扩展

如果你只是拿这套系统应付毕业设计，跑到这里其实已经足够完整了——有登录、有权限、有核心业务、有统计报表。但如果你想让它更有竞争力，往这几个方向扩展会非常加分：一是把统计报表从传统的ECharts柱状图升级成实时大屏，把隔离点入住率、每日体温异常数、解除隔离趋势都做成动态可视化面板；二是引入定时任务，每天早上自动给未上报健康数据的隔离人员发送提醒，SpringBoot做这个只需要加一个@Scheduled注解然后写个DingTalk或者邮件通知的工具类；三是用Redis做验证码缓存和登录状态管理，比单机Session的方案更接近真正的生产环境。

我个人在实际操作中的一个体会是，这种管理系统项目最容易出问题的地方永远不在技术本身，而在对业务规则的理解。比如"解除隔离"的条件是什么、"房间分配"状态怎么流转、审批拒绝之后怎么回滚状态，这些代码量不大但包含大量细节，也是最容易在答辩时被提问的地方。建议拿到源码后先把隔离人员从登记到解除的整条状态链路画出来，把每一种状态的触发条件和禁止条件弄清楚，再去跑功能，思路会清晰很多。

最后分享一个小技巧：如果你要把这套源码作为自己的毕设，千万别只改个页面标题就交差。挑一个功能模块做深度改造，比如把健康上报从手动输入改成批量导入，或者给数据统计增加导出Excel的功能，改动不大但在老师眼里完全是两件事。源码是别人的，但改造思路和分析过程是你自己的，这一点在答辩时尤其重要。