前阵子刚交付完一套疫情隔离管理系统后端SpringBoot MyBatis前端Vue Element UI数据库用的MySQL整个项目属于比较典型的企业级管理系统。整理源码的时候不少朋友来找我聊说这套系统的完整源码和设计思路对他们很有帮助。今天干脆把它拆开来讲清楚需求怎么梳理的、数据库怎么设计的、前后端怎么做联调、部署上线又踩了哪些坑一条线都写出来想学习SpringBoot全栈开发或者准备做类似管理系统的朋友可以直接参考。这个系统表面上是个CRUD项目真正做起来才发现核心难点全都在“状态流转”和“健康数据统计”上。隔离记录从申请、审批、隔离中到解除每一步都要有痕迹健康上报数据要按人、按部门、按日期做多维统计。这些如果一开始没想清楚后面写代码会非常痛苦。我先把整个项目的设计过程和技术细节完整复盘一遍。1. 隔离管理系统的需求画像哪些功能真的值得做很多初级开发者拿到管理系统需求上来就建表写CRUD结果做到一半发现审批流程不通、统计报表对不上。我这里先花时间把需求边界划清楚哪些是必须做的核心哪些是看起来炫但实际没必要的东西。1.1 核心链路申请-审批-隔离-上报-解除隔离管理系统的业务主链路其实很清晰某员工需要进入隔离观察先走申请流程管理员或审批人审核通过后该人员进入“隔离中”状态隔离期间每天要上报体温和健康状况到期后系统自动或人工操作解除隔离生成完整的隔离台账记录。拆解下来就是以下四个核心业务域隔离台账记录“谁、从什么时候到什么时候、因为什么原因、在哪个地点”隔离这是所有业务的基础。审批流程申请提交后要有审批环节通过或驳回要留痕操作人和审批意见都要可追溯。健康上报隔离期间每天上报体温、症状等健康数据支持批量导入超时未报要有提醒。统计分析按部门、按时间维度统计隔离人数、健康异常人数、解除率等指标给管理层做决策参考。这四个业务域缺一不可也是这套系统源码中代码量最大、最值得研究的部分。1.2 权限与数据范围企业级系统和Demo最本质的区别标题里带了“企业级”三个字这里就得认真聊聊。企业级管理系统和普通教学Demo最大的区别就是需要考虑多角色、多部门、数据权限隔离。这个系统里的角色大致分为三类普通员工能提交隔离申请上报个人健康数据查看自己的隔离记录。部门管理员能审批本部门员工的申请查看本部门的隔离台账和统计报表。系统管理员能管理用户、部门、配置隔离地点查看全量数据处理异常记录。数据权限这块用部门ID来做隔离普通员工只能看自己数据部门管理员只能看本部门数据。这个设计虽然不是特别复杂但一定是“企业级”系统绕不开的一环我在源码里做了完整的实现后面讲权限设计时会展开。1.3 明确不做什么需求收敛也是能力做企业项目最怕需求蔓延。有不少人问我要不要加地图热力图、大屏可视化、消息推送我的建议是版本一先砍掉。隔离管理系统最核心的价值是把流程跑通、数据记录准确花里胡哨的东西等主干稳定后再迭代。我最后只保留了一个基础的数据看板用ECharts展示趋势数据既满足管理层看数需求又不至于把整体复杂度抬太高。2. 技术选型与整体架构为什么要用这套组合技术选型不能跟风要结合团队熟悉度、项目规模、部署环境来做决定。这套系统为什么选SpringBoot Vue MyBatis MySQL每一项都有具体的理由。2.1 后端选型SpringBoot 2.7 MyBatis的取舍逻辑SpringBoot在Java后端领域已经是非常成熟的选择或者说已经是事实标准。隔离管理系统这种典型的企业级Web应用涉及大量的增删改查、事务处理、定时任务、文件上传SpringBoot都能提供非常好的支持。我用的是SpringBoot 2.7.x版本搭配JDK 8这套组合在企业的存量环境中兼容性极好。为什么ORM选MyBatis而不是JPA/Hibernate从我实际开发经验来看这个系统的统计数据复杂度和SQL灵活度都比较高。比如“查询每个部门每日的隔离人数变化趋势”这种需求JPA写起来非常别扭而MyBatis配合动态SQL可以写得很自然。还有一个关键点国内企业团队对MyBatis的熟悉程度普遍更高后期维护门槛更低。隔离管理系统的SQL本身就包含多表关联、动态条件、分组统计MyBatis的XML映射文件让SQL的维护和调优都变得可掌控。2.2 前端选型Vue 2 Element UI的稳妥路线前端用了Vue 2 Element UI可能有人会问为什么不上Vue 3 Element Plus。原因很实际这套项目面向企业交付Vue 2生态里的Element UI组件库极其成熟表格、表单、弹窗、日期选择这些后台管理常用组件都能直接上手。对于隔离管理这种重表格、重表单、轻交互的项目Element UI的代码效率非常高。如果团队刚接触Vue没多久Vue 2的学习资料也是最多的上手难度最低。前端工程化这块用标准的Vue CLI搭建配合Vue Router做路由管理、Vuex做全局状态管理、axios做HTTP请求。页面主要分为登录页、隔离台账页、健康上报页、审批处理页、统计看板页和用户/部门管理页整体结构清晰后续单独拎出来任何一个模块都可以复用。2.3 数据层选型MySQL 8.0与日常使用细节数据库用的MySQL 8.0。相比5.78.0在窗口函数、公用表表达式CTE、JSON支持、性能优化上都强不少。虽然隔离管理系统核心功能用不上窗口函数但统计趋势类需求如果有人想用8.0的支持会舒服很多。字符集统一用utf8mb4排序规则用utf8mb4_general_ci连接串上显式加上serverTimezoneAsia/Shanghai和useSSLfalse这两个参数能避免掉九成开发和部署过程中的时区报错和SSL告警问题。3. 数据库设计核心表结构与关键字段的思考数据库设计是整个系统工程质量的地基表结构设计不合理后面写Mapper和Service再牛也白搭。下面重点讲核心表的设计思路。3.1 人员信息与隔离记录表设计隔离模块的核心表是isolation_record也就是隔离记录表。设计它的时候有几个关键字段的取舍值得展开说。CREATE TABLE isolation_record ( id bigint(20) NOT NULL AUTO_INCREMENT, person_name varchar(64) NOT NULL COMMENT 姓名, id_card varchar(18) NOT NULL COMMENT 身份证号, department varchar(128) NOT NULL COMMENT 所属部门, phone varchar(20) DEFAULT NULL COMMENT 手机号, reason varchar(255) NOT NULL COMMENT 隔离原因, location varchar(255) NOT NULL COMMENT 隔离地点, start_date date NOT NULL COMMENT 隔离开始日期, end_date date NOT NULL COMMENT 预计解除日期, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0待审批 1隔离中 2已解除 3已拒绝, version int(11) NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, create_by varchar(64) DEFAULT NULL COMMENT 创建人, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_status_startdate (status, start_date), KEY idx_department (department) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT隔离记录表;有几个设计细节说一下。状态字段status我用的tinyint数字枚举而不是字符串原因是数字枚举查询更快、存储更省代码里配合常量类或枚举类可读性完全没问题。version字段是为乐观锁准备的审批这种多步操作场景两个管理员同时审批同一条记录的概率虽然不高但一旦出现就会产生状态覆盖问题乐观锁能从根本上避免。联合索引idx_status_startdate的服务对象是“按状态日期范围筛选”这种最常见的高频查询。人员基本信息我没有单独建表而是直接冗余到隔离记录里。理由是隔离场景下人员信息相对稳定冗余字段能避免一次查询要JOIN多张表的问题。如果后续要做完整的人员档案管理再拆出person表也不迟。3.2 健康上报与审批记录表设计健康上报表health_report是隔离期间每天产生数据的地方这个表的特点是写入频繁、查询按人和日期维度。CREATE TABLE health_report ( id bigint(20) NOT NULL AUTO_INCREMENT, record_id bigint(20) NOT NULL COMMENT 关联隔离记录ID, report_date date NOT NULL COMMENT 上报日期, temperature decimal(4,1) NOT NULL COMMENT 体温, health_status tinyint(4) NOT NULL DEFAULT 0 COMMENT 健康状况0正常 1异常, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_record_date (record_id, report_date), KEY idx_report_date (report_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT健康上报表;这个表最关键的是唯一索引uk_record_date同一人同一天只能有一条上报记录天然避孕了重复提交问题。为什么用唯一索引而不是在代码里先查再插因为代码判断存在并发窗口唯一索引是数据库层面的硬约束两者配合才最稳。审批记录表approval_record是个通用设计通过biz_type区分业务类型隔离审批、解除审批等用biz_id关联具体业务主键。这样做的好处是后续无论新增什么审批流程都不需要改表结构直接复用。3.3 用户、角色与部门的数据权限设计系统用户这块我用的是典型的RBAC模型sys_user用户表、sys_role角色表、sys_user_role用户角色关联表外加sys_dept部门表。用户表里除了常规的账号密码、姓名、部门ID、角色外还存了status字段控制账号启停。数据权限的核心实现思路是这样部门管理员登录后后端在Token解析阶段取出用户的部门ID和角色标识然后注入到每次查询的过滤条件中。具体来说就是所有查询接口都要求传入deptIdService层根据当前登录用户的角色判断是否强制追加部门过滤条件。这个逻辑统一封装新写接口不会遗漏权限安全性和业务开发的效率兼顾了。4. 后端核心业务实现从Controller到SQL的完整链路这一部分重点讲后端代码的组织方式和几个关键业务的实现链路尤其是审批状态流转、健康上报和统计查询。4.1 统一返回体、全局异常与JWT鉴权后端代码工程结构按照标准的四层来组织Controller负责接口定义和参数校验Service负责业务逻辑Mapper负责数据库操作再加上统一的DTO/VO对象。这种分层是企业级项目的底线隔离管理系统的业务状态流转多如果都堆在Controller里后期改一个审批逻辑会牵连出一堆问题。统一返回体ResultT是每个接口的固定包装里面包含code、msg、data三个字段。成功时code为200业务异常时code为具体错误码未登录或Token失效返回401。配合全局异常处理器RestControllerAdviceService层只需要抛业务异常最终都会转换成规范的JSON结构返回给前端前端不用为异常情况写一堆if-else。鉴权用的JWT处理思路是登录成功生成Token返回给前端前端存到localStorage之后每次请求在请求头带token字段。后端的拦截器拦截除了登录接口之外的所有请求解析Token校验有效性并往ThreadLocal里放入当前用户的ID、部门ID、角色标识。后面任何Service层方法需要获取当前登录人信息时直接从ThreadLocal拿代码非常干净。4.2 隔离申请与审批的核心状态机这个系统里最有技术含量的部分是隔离记录的状态变化。我直接用状态机的方式来做约束明确每个状态允许流转到哪些状态。下面是隔离审批Service层的一个核心片段。Service public class IsolationRecordServiceImpl implements IsolationRecordService { Override Transactional(rollbackFor Exception.class) public void approve(ApproveRequest req) { IsolationRecord record recordMapper.selectByIdForUpdate(req.getRecordId()); if (record null) { throw new BizException(ErrorCode.RECORD_NOT_EXIST); } // 只有待审批(PENDING)状态才能审批 if (record.getStatus() ! IsolationStatus.PENDING.getCode()) { throw new BizException(ErrorCode.STATUS_NOT_ALLOWED); } // 状态流转待审批 - 隔离中 / 已拒绝 Integer targetStatus req.getAction() 1 ? IsolationStatus.ISOLATING.getCode() : IsolationStatus.REJECTED.getCode(); record.setStatus(targetStatus); recordMapper.updateById(record); // 记录审批痕迹 ApprovalRecord approval new ApprovalRecord(); approval.setBizType(ISOLATION); approval.setBizId(record.getId()); approval.setApprover(getCurrentUserId()); approval.setAction(req.getAction()); approval.setComment(req.getComment()); approvalMapper.insert(approval); } }几个要点值得展开。selectByIdForUpdate是悲观锁因为审批是敏感操作宁可多等一个事务也不允许并发情况下两个人同时审批。加锁之后判断状态必须是待审批这避免了已审批过的记录被再次操作。审批人和审批意见都会写入approval_record任何一条状态变更都有完整痕迹可查。同样的思路延伸到解除隔离操作解除接口也必须校验当前状态是“隔离中”。4.3 每日健康上报的批量与自动兜底健康上报模块支持两种方式手动逐条上报和Excel批量导入。手动上报就是一个简单的插入接口有唯一索引兜底重复提交。Excel批量导入这里多说两句我用的是EasyExcel相比传统的POI操作EasyExcel在内存占用上优势很大几万行的导入也不会OOM。导入的流程固定为上传文件、解析数据、逐行校验、批量插入、返回失败行号和原因。这里还有个业务痛点很多隔离人员会忘记上报。我的处理方式是加一个定时上报提醒任务每天早上8点扫描今天应该上报但还未上报的隔离记录给相关负责人发送提醒通知。实现非常简单Spring自带的Scheduled注解就可以。Component public class HealthReportRemindTask { Scheduled(cron 0 0 8 * * ?) public void remindUnreported() { ListIsolationRecord unReportedRecords reportMapper.listUnreportedToday(); // 逐个发送短信/内部消息提醒 for (IsolationRecord record : unReportedRecords) { notifyService.sendRemind(record.getPhone(), record.getPersonName()); } } }4.4 MyBatis动态SQL在复杂统计中的实战用法统计报表是这套系统里SQL技术含量最高的模块。比如“查询最近14天每天处于隔离中的人数”这个需求直接查记录表把每天新增和解除的数字做加减。下面这个动态SQL是我在实践中调了好几次才满意的select idcountDailyIsolating resultTypemap SELECT date_list.day, COUNT(CASE WHEN r.start_date lt; date_list.day AND (r.end_date gt; date_list.day OR r.status 1) THEN 1 END) AS isolating_count FROM ( SELECT DATE_SUB(CURDATE(), INTERVAL seq.day DAY) AS day FROM ( SELECT 0 AS day UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 ) seq ) date_list LEFT JOIN isolation_record r ON r.status IN (1, 2) GROUP BY date_list.day ORDER BY date_list.day /select上面这段SQL的思路是先用子查询构造出最近7天的日期序列再关联隔离记录表统计每一天处于隔离中的有效人数。重点是隔离状态的语义开始日期小于等于目标日期结束日期大于等于目标日期或者还没解除状态为1。这种统计口径容易错要特别注意。5. 前端Vue工程实现管理后台的界面、路由与状态管理后端解决了业务逻辑前端要做的是把这些能力转化成可操作的界面。管理系统的前端开发核心在于规范性和复用性页面多、接口多必须有一套统一的约定才能不越写越乱。5.1 工程目录划分与路由权限控制前端工程初始化之后第一件事就是规划目录结构。我的划分方式是api目录统一存放所有后端接口调用定义按业务模块拆分文件views目录存放页面组件router目录存放路由配置store目录放Vuex状态utils目录放axios封装、日期工具、权限指令等公共代码。这个结构看起来朴素但在多人协作时大家拿过来就知道该往哪个目录放代码。路由权限控制是管理系统前端必做的。Vue Router的全局前置守卫每次路由跳转前检查Vuex里有没有用户信息和Token没有就跳登录页有的话再判断当前路由的meta.roles是否包含当前用户的角色。隔离管理系统的角色有三种路由表里通过meta.roles声明可访问角色后端接口也做了同样的校验前端是体验优化后端才是安全底线。5.2 axios二次封装与接口联调规范axios必须二次封装不然几十个页面里重复写请求头和处理错误后续改一处要前面几十处。下面这段代码是比较经典的封装方式。const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 15000 }) // 请求拦截器自动带Token service.interceptors.request.use(config { const token getToken() if (token) { config.headers[token] token } return config }) // 响应拦截器统一处理返回码 service.interceptors.response.use( response { const res response.data if (res.code 200) { return res } if (res.code 401) { removeToken() router.push(/login) return Promise.reject(new Error(登录状态已过期)) } Message.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg)) }, error { Message.error(error.message) return Promise.reject(error) } )这里统一处理401的用意是系统部署久了Token总会过期不能让用户看到白屏直接跳回登录页重新登录产品体验明显好一截。接口定义上也遵循一个约定所有方法都写成可导出的函数页面引用的地方只关心参数和返回的数据结构不用管HTTP细节。5.3 核心页面模块台账表格、卡片上报和统计看板隔离台账页是这个系统的门面数据表格加上筛选栏是个非常通用的组合。筛选条件包括姓名、部门、状态、隔离日期区间筛选逻辑全部走后端分页查询前端只是同步查询参数。操作列根据当前行状态动态渲染按钮待审批状态显示“审批”隔离中状态显示“解除”这样操作语义清晰也避免了误操作。健康上报页我把它设计成卡片式布局每人一张卡片显示姓名、隔离天数、体温和健康状态。隔离人员的健康数据通过ECharts折线图展示体温变化趋势一眼就能看出体温有没有异常波动。这里需要补充的是ECharts的option配置可以抽成一个公共方法不同页面传入不同数据即可不然每个页面复制一大段配置会很痛苦。统计看板页是管理层看得最多的页面包括今日隔离总人数、待审批数量、健康异常数量、近7天趋势图。这些数据都来自后端统计接口前端展示上注意加载状态的处理因为首次进入看板要同时发三四个请求我用Promise.all统一处理加载态避免页面一卡一卡的。6. 端到端联调与部署真正跑起来的那些细节代码写完不等于项目做完真正的工作量在后半段——联调、部署、修问题。这一部分分享一下完整跑通项目的经验。6.1 前后端接口规范与Mock联调前后端并行开发时接口必须提前约定好。我的做法是在项目初期就把所有接口的路径、请求参数、响应结构、状态码约定写到接口文档里然后前端根据约定用Mock数据开发页面后端按约定实现接口。前端统一用axios封装的service方法请求后端之后联调时只需要把Mock地址改成后端地址。这个流程跑顺之后前后端联调基本没有大摩擦。接口规范有几个细节值得养成习惯分页接口统一用pageNum和pageSize返回参数返回体用{ list, total }结构所有日期时间字段统一用字符串传输格式为yyyy-MM-dd HH:mm:ss所有金额、温度等数值类型统一在后端处理精度前端不做计算。这些约定能在实际联调中省下大量时间。6.2 后端Jar包打包与前端Nginx发布后端部署没有什么花哨的用Maven打包成可执行的Jar包服务器上装好JDK 8直接nohup java -jar isolation-system.jar 启动然后用SpringBoot Actuator的/actuator/health接口做健康检查。生产环境需要注意设置JVM参数-Xms和-Xmx至少512M起步隔离管理系统的并发量不会特别极端但JVM参数不设默认堆太小高峰期容易卡顿。前端打包之后是一堆静态资源用Nginx托管。Nginx配置里有两个关键点一是location /api/前缀的请求要反向代理到后端服务二是非/api路径的请求都指向index.html否则Vue Router的history模式一刷新页面就会404。这两个点也是部署阶段最容易踩坑的地方。6.3 部署后的环境修复时区、跨域、静态资源路径我部署这套系统时遇到的第一个问题是数据库连接串没加serverTimezone参数导致写入的时间比实际时间早了8个小时。排查方式也很直接先看SQL日志里传入的时间再看库里实际存的时间对比后发现是驱动没有设置时区。在application.yml的JDBC连接串上补上serverTimezoneAsia/Shanghai就解决了。第二个问题是开发环境的跨域。前端开发服务器跑在8080端口后端跑在8081端口浏览器会拦截跨域请求。我在Vue CLI的vue.config.js里配置了devServer代理把/api前缀全部转发到http://localhost:8081这样开发环境下前端请求看起来是同源的后端不需要额外配置CORS。生产环境Nginx反向代理后自然也没有跨域问题。7. 我踩过的坑和几个值得直接抄的优化点每个项目做下来都有几个印象深刻的问题有的是因为测试不充分有的是因为对框架理解不到位。这里挑三个最有代表性的展开讲都是我实际遇到过、花了时间才解决的。7.1 坑一日期区间查询的索引失效问题台账页面的查询条件里有“按隔离日期筛选”的功能。一开始我的SQL写成DATE_FORMAT(start_date, %Y-%m-%d) ?结果数据量一上来查询耗时直接飙升到好几秒。原因很明确对索引列使用函数后MySQL无法应用索引只能全表扫描。解决方式很简单改成start_date ? AND start_date ?直接对裸列进行范围判断并用上idx_status_startdate索引。这里有个通用教训想让索引生效就尽量不要在WHERE子句中对索引列做任何函数运算传参时把日期格式处理好。确实需要格式化输出的场景应该把函数写成DATE_FORMAT(start_date, ...) AS formatted_date放SELECT层而不是放WHERE层。7.2 坑二前端JavaScript精度丢失与Long类型ID序列化这个坑不急时发现不了等隔离记录数量超过一定范围时才暴露出来。Java后端的记录主键是Long类型当ID超过JavaScript的Number.MAX_SAFE_INTEGER时前端接收JSON后精度会丢失导致点击“审批”按钮时传给后端的ID和真实ID不一致接口直接报“记录不存在”。解决方案是在实体类的主键ID字段上加JsonSerialize(using ToStringSerializer.class)注解让JSON序列化时把Long转成字符串输出。前端拿到的是字符串操作时原样传回不涉及精度问题。这个改完好几个类似的列表页都稳定了。7.3 值得直接抄的优化点Redis缓存与数据脱敏除了修坑我还做了两个值得说的优化。第一个是接入Redis做缓存主要是登录验证码和热点统计数据。每天的“今日隔离总人数”这个数字会被看板页反复查询第一次查完放进Redis设置5分钟过期之后请求直接走缓存数据库压力明显下降。第二个是数据脱敏身份证号码在列表页只显示前6位和后4位中间用星号代替详情页有权限的人才看得到全量。疫情隔离系统涉及人员健康数据隐私保护是必须考虑的责任代码里我特意做了这个设计。另外Excel导入这个功能也可以在原有基础上迭代比如增加异常数据的在线编辑修正避免导入失败后重新整理整个表格。这个属于体验层面的优化后续版本可以按需开发。做完整套系统回头来看这个项目的核心价值不在代码本身而在于完整经历了一个“需求分析-表结构设计-后端实现-前端开发-联调部署”的闭环。尤其是状态机的设计和数据权限的处理是工程师从“会写CRUD”到“能设计系统”的关键分水岭。源码我整理的时候尽量保持了结构和注释的清晰度遇到问题多调试几遍会有非常大的收获。