接手这个项目的时候我其实挺有感触的。疫情隔离管理这类系统看着是常规的信息化建设但真正做起来才发现SpringBoot Vue MyBatis MySQL这套技术栈在企业级场景下踩的坑全藏在人员流转、健康监测、数据上报、权限控制这些具体业务里。标题里企业级完整版这两个词意味着它不是一个教学Demo而是要考虑并发、权限、数据准确性和可维护性的交付物。这篇文章就围绕这套系统的完整实现过程从需求拆解到技术选型从后端骨架到数据库设计把关键代码和踩坑经验一起捋一遍希望对正在做同类管理系统的朋友有直接帮助。1. 疫情隔离管理系统的业务边界先搞清楚要管什么1.1 隔离点日常运转的真实痛点很多人一听到隔离管理系统第一反应是不就是做个登记表吗实际上隔离点的业务远比想象中复杂。一个标准隔离点每天要处理这几类高频事务新 arrival 人员登记入住、每日体温与症状上报、核酸结果回填、隔离期满转出、异常人员转诊、医护排班与任务分派以及防护服、口罩、消毒液等物资的出入库。这里面的核心难点在于状态流转。隔离人员不是静态数据他的状态会经历待入住、在隔、异常待转、已解除、已转出等阶段每个状态变更都可能触发后续动作。比如体温连续两次超过37.3℃系统要自动预警并把人员标记为异常同时生成待办事项推送给值班医护。这个过程如果仅仅靠一张表存数据业务逻辑会彻底失控。1.2 系统的核心业务闭环前期梳理需求时我把整个系统拆成了五个核心域业务域核心功能关键状态/字段人员管理入住登记、档案维护、状态流转姓名、证件号、入住时间、隔离类型健康监测每日体温/症状上报、核酸记录体温、症状描述、核酸结果、上报时间隔离记录隔离批次、解除/转出登记开始时间、预计结束时间、实际结束时间医护管理排班、任务分派、异常处理值班日期、负责楼栋、处理状态物资管理出入库、库存预警、领用登记物资名称、数量、领用人、领用时间这五个域一起构成闭环人员来了登记入住每天健康上报数据异常触发预警医护处理异常并记录转归解除隔离后回写入住档案。所有环节的数据最终汇总到统计报表供管理者查看隔离人数、健康率、物资消耗趋势。这个业务闭环就是整个系统的北极星后面所有技术设计——数据库表结构、接口划分、前端页面组织都必须围着它转。开发组内部我常说一句话先让业务闭环保得住再谈技术架构。业务流没理清楚就急着编码返工成本会是灾难级的。2. 技术选型分析为什么是SpringBoot Vue MyBatis MySQL这套组合2.1 选型逻辑企业级交付的权衡这套技术栈组合乍看平平无奇但放到企业级交付场景里它其实是经过了多层权衡的结果。我分别说说每个组件承担的角色。SpringBoot解决的是后端快速交付和生态整合问题。企业级项目最怕的是框架卡脖子SpringBoot的自动配置机制和starter生态能让团队把精力集中在业务代码上。比如内部接口用spring-boot-starter-web权限校验用spring-boot-starter-security或自定义拦截器数据库交互用mybatis-spring-boot-starter。版本升级也有成熟路径不像某些自研框架改一版死一片。MyBatis的选择可能有人会质疑为什么不直接用JPA这里说句实话复杂统计查询是这类系统的刚需而MyBatis对SQL的可控性、对多条件动态拼接的支持在报表类场景里有着明显优势。JPA虽然开发快但遇到那种跨三张表、六种筛选条件、还要分组统计的SQL调试成本远高于MyBatis里写一条provider动态SQL。尤其隔离管理系统的数据统计维度多按日期、按楼栋、按状态、按性别MyBatis这种半ORM模型正好卡在了开发效率和SQL可控性的最佳平衡点上。2.2 前端和后端的分工边界Vue的选择基本是当下企业级中后台的默认答案。前后端分离的结构下Vue负责页面交互、状态管理、路由控制后端只关心业务逻辑和返回JSON。这套系统里权限控制是一个绕不开的点——管理员、医护、隔离人员三种角色的操作边界完全不同前端利用 Vue Router 的导航守卫做路由级拦截后端再用 JWT 做接口级校验双重保障。MySQL在这个系统里承担的是数据准确性的责任。虽然隔离管理系统的数据量不大一个隔离点同时在线几百人算多的了但事务的可靠性是硬要求。比如物资出库时既要扣减库存又要写领用记录这两个操作必须保证要么都成功要么都失败MySQL的InnoDB事务在这里就是基础设施。加上MySQL本身的运维生态成熟中小型团队都能轻松维护。2.3 为什么不选微服务 / 为什么不用NoSQL开头提到企业级有的朋友可能觉得企业级微服务。这个认知需要纠正。我在需求评审时说过微服务的复杂度必须由业务复杂度来买单隔离管理系统这种单体就能跑得非常好的业务强行上微服务光服务间调用、链路追踪、分布式事务就能把团队拖垮。数据存储层面有人建议用Redis缓存人员信息。这个可以做但要分场景高频读取的基础数据比如楼栋列表、物资分类可以加缓存人员健康记录这种强一致性数据绝不能先写缓存再同步数据库这属于自找麻烦。MySQL在万级数据量下的表现完全够用垂直优化一下索引就足够了。3. 后端核心模块的实现思路与代码骨架3.1 先搭好地基统一响应与全局异常处理企业级系统最怕接口返回格式五花八门。开发初期我强制定了一条规矩所有接口必须走统一响应体。这个规范越早定越好不然后端写一个样前端对接的时候能吵起来。统一响应体我简单展示一下Data public class ResultT { private Integer code; private String message; private T data; private Long timestamp; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); result.setTimestamp(System.currentTimeMillis()); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); result.setTimestamp(System.currentTimeMillis()); return result; } }配套的全局异常处理用RestControllerAdvice实现拦截BusinessException、参数校验异常、数据库异常统一转成上述格式。这个地基搭好之后前端可以用一个统一的响应拦截器处理所有接口的 code、message、data不用每个接口单独判断。成本不高但后期维护舒适度提升巨大。3.2 隔离人员全生命周期管理状态机设计隔离人员是系统的核心主体我的设计思路是把他抽象成一条状态流待入住 - 在隔 - 解除/转出中间穿插异常这一特殊状态。状态流转必须走统一入口避免业务代码里散落着一堆直接改status字段的野路子。先设计一个枚举类public enum IsolationStatus { PENDING(0, 待入住), IN_ISOLATION(1, 在隔), ABNORMAL(2, 异常待处理), RELEASED(3, 已解除), TRANSFERRED(4, 已转出); private final int code; private final String desc; IsolationStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态流转逻辑我放在Service层统一处理——比如confirmArrival()确认入住、reportAbnormal()标记异常、completeIsolation()解除隔离。这样做的最大好处是业务规则集中比如异常状态的人员不允许直接解除隔离必须转出或经医护确认这条规则写在Service里任何入口调用都会经过校验。3.3 健康监测与预警定时任务 触发器思维健康上报是每天的高频操作隔离人员或者代填的医护每天上报体温和症状。这里的核心不是存数据而是趋势判断。我定义了两个预警维度单次异常体温大于37.3℃立即标黄连续异常同一人员连续两次上报体温大于37.3℃自动转异常待处理状态并生成待办连续异常的判断在SQL层面就好处理写一个查询最近两条记录的方法select idselectLastTwoHealthRecords resultTypeHealthRecord SELECT * FROM health_record WHERE person_id #{personId} ORDER BY report_date DESC, report_time DESC LIMIT 2 /select拿到后逐条比较连续两次超标就触发预警。这类规则如果做复杂了可以引入规则引擎但当前规模下Java代码里一段if判断就是最清晰高效的实现杀鸡不用牛刀。3.4 MyBatis动态SQL在复杂统计查询中的应用这套系统里最有技术含量的一段SQL是综合统计报表要按日期、楼栋、状态维度统计隔离人数和健康情况。多条件组合查询是MyBatis的强项我这里用where配合if标签做动态拼接select idselectStatsList resultTypemap SELECT DATE_FORMAT(hr.report_date, %Y-%m-%d) AS stat_date, b.building_name AS building_name, COUNT(DISTINCT hr.person_id) AS total_people, SUM(CASE WHEN hr.temperature 37.3 THEN 1 ELSE 0 END) AS abnormal_count FROM health_record hr LEFT JOIN isolation_person p ON hr.person_id p.id LEFT JOIN building b ON p.building_id b.id where if teststartDate ! null and startDate ! AND hr.report_date gt; #{startDate} /if if testendDate ! null and endDate ! AND hr.report_date lt; #{endDate} /if if testbuildingId ! null AND p.building_id #{buildingId} /if if teststatusCode ! null AND p.status #{statusCode} /if /where GROUP BY stat_date, b.building_name ORDER BY stat_date DESC /select动态SQL最大的价值在于查询条件可组合页面勾选什么筛选条件就拼接什么不需要为每种组合单独写一条SQL。但注意测试时必须把每种组合都跑一遍否则容易出现某个条件漏拼导致的统计偏差。3.5 权限控制JWT 拦截器的轻量方案企业级系统的权限控制要分层。后端我的做法是JWT认证 拦截器鉴权。登录接口校验账号密码后签发tokentoken里携带用户id和角色code拦截器从请求头摘出token并校验角色public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); } try { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(roleCode, claims.get(roleCode)); return true; } catch (Exception e) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\登录状态已失效\}); return false; } } }角色接口级校验我用RequireRole(ADMIN)这类自定义注解 AOP去做。比如物资管理模块只允许管理员操作隔离人员只能查看自己的健康记录和隔离信息。这套轻量方案在企业级场景里够用且好维护比引入Spring Security的全量配置更直观适合内部管理系统的权限复杂度。4. 数据库设计隔离管理场景下的表结构规划与索引优化4.1 核心表结构概览数据库设计我遵循按业务域分表、按查询场景建索引的原则。核心表包括isolation_person隔离人员、health_record健康记录、isolation_record隔离记录、building楼栋、nurse_task医护任务、material_stock物资库存、material_log物资流水。以isolation_person为例关键字段设计CREATE TABLE isolation_person ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, name varchar(50) NOT NULL COMMENT 姓名, id_card varchar(18) NOT NULL COMMENT 证件号, gender tinyint DEFAULT 0 COMMENT 性别0未知 1男 2女, phone varchar(20) DEFAULT NULL COMMENT 联系电话, building_id bigint DEFAULT NULL COMMENT 楼栋id, room_no varchar(20) DEFAULT NULL COMMENT 房间号, status tinyint DEFAULT 0 COMMENT 状态0待入住 1在隔 2异常 3解除 4转出, isolation_type tinyint DEFAULT NULL COMMENT 隔离类型1密接 2次密接 3入境 4其他, arrival_time datetime DEFAULT NULL COMMENT 入住时间, expect_release_time datetime DEFAULT NULL COMMENT 预计解除时间, actual_release_time datetime DEFAULT NULL COMMENT 实际解除时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_id_card (id_card), KEY idx_status (status), KEY idx_building_id (building_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT隔离人员表;几个设计要点值得说一下证件号唯一约束是硬性要求一个人同一时间不能重复隔离。所以id_card建了唯一索引后续重复登记直接报错应用层再给出友好提示。状态字段建议用数字枚举不要直接存中文。数据库层面数字更快、占用空间更小查询时的中文含义映射放到Java枚举里去做。时间字段全部用datetime避免用varchar。真实项目里我见过把时间存成字符串的表后来做日期范围统计时全是坑索引也白加了血的教训。4.2 高频查询与索引策略隔离点的高频查询几乎都围绕今天的健康上报名单和当前在隔人员列表展开。我给health_record表建了一个组合索引ALTER TABLE health_record ADD INDEX idx_person_date (person_id, report_date);这个索引最典型的查询是查某个人某一天的记录两条查询条件正好命中复合索引前缀效率极高。如果哪天系统数据量涨到百万级还能在这个基础上配合分区表按月份做分区不过现有规模完全没必要。4.3 一对多关系查询的N1问题隔离人员查健康记录天然是一对多查询。如果代码写法是先查人再循环查记录当列表灌满几百人时数据库要被查几百次性能直接雪崩。MyBatis里我利用collection做了嵌套结果映射一次性联表查出人员和当天记录resultMap idIsolationPersonWithHealthMap typeIsolationPerson id propertyid columnid/ result propertyname columnname/ collection propertyhealthRecords ofTypeHealthRecord id propertyid columnhr_id/ result propertytemperature columntemperature/ result propertyreportTime columnreport_time/ /collection /resultMap select idselectPersonWithTodayHealth resultMapIsolationPersonWithHealthMap SELECT p.id, p.name, hr.id AS hr_id, hr.temperature, hr.report_time FROM isolation_person p LEFT JOIN health_record hr ON p.id hr.person_id AND hr.report_date #{today} WHERE p.status 1 /select这个技巧在MyBatis里很常见但新手容易踩坑collection 映射时如果关联字段为空记得用LEFT JOIN并允许null否则查出来的列表会比实际少人。这个细节在测试不多的时候最容易漏掉。5. 前端工程化与关键交互细节5.1 Vue项目结构与动态路由前端用Vue 3 Vite Element Plus Vue Router Pinia标准的后台管理模板。项目目录按业务分开views 下保持和后端接口一一对应的组织方式src/ ├── api/ # 接口请求封装 │ ├── person.js │ ├── health.js │ └── stats.js ├── views/ │ ├── person/ # 人员管理页面 │ ├── health/ # 健康监测页面 │ ├── building/ # 楼栋管理 │ └── material/ # 物资管理 ├── router/ │ └── index.js # 路由配置 └── store/ # Pinia状态管理权限控制方面我在路由配置里给每个页面添加 meta 字段标记角色权限前端路由守卫判断当前登录用户的角色是否有权访问{ path: /material, component: Layout, meta: { roles: [ADMIN] }, children: [ { path: stock, component: () import(/views/material/stock.vue), meta: { title: 库存管理, roles: [ADMIN] } } ] }5.2 axios封装与接口对接细节企业级项目里接口请求不能裸调。我封装了一个request工具统一挂上JWT token、统一解析Result响应体、统一处理401跳登录、统一展示错误信息。import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 15000 }) 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) { return res.data } if (res.code 401) { localStorage.removeItem(token) router.push(/login) return Promise.reject(new Error(res.message)) } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(error.message || 请求失败) return Promise.reject(error) } )这里有个重要细节axios拦截器里统一把res.data解出来页面里request.get(/person/list)直接拿到的就是数据体不需要每页再写一次res.data.data的嵌套判空。这个约定全组统一能省下大量冗余代码。5.3 统计图表与数据可视化管理端大屏需要展示隔离人数趋势、各楼栋健康状态、物资库存水位。图表我用的ECharts封装成通用组件。需要注意的点组件卸载时记得销毁图表实例否则页面频繁切换会有内存泄漏和渲染错乱。一个简单做法是在onUnmounted里调用chart.dispose()。统计接口返回的数据结构要和前端图表组件对齐。比如折线图需要{ xAxisData: [01-01,01-02], seriesData: [20, 30] }这个结构在后端组装好再返回前端只负责渲染避免前端去重写一堆数组处理方法。6. 部署上线与企业级安全细节6.1 前后端分离部署配置项目交付时前后端分离部署我在生产环境给出一套标准拓扑后端SpringBoot打成jar包运行在8080端口前端Vue打包后的静态资源由Nginx托管Nginx再把/api前缀的请求反向代理到后端。Nginx配置是这样的server { listen 80; server_name 192.168.1.100; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }try_files那行必须加否则 Vue 路由在 history 模式下前端页面刷新会出现404白屏问题。我遇到过不少同事在这个地方卡到怀疑人生。6.2 配置外置与环境隔离企业级交付最忌讳配置文件硬编码。application.yml里数据库密码、JWT密钥这些敏感信息千万别写在代码仓库里。我习惯用bootstrap.yml配合application-prod.yml做环境隔离部署时通过命令行指定profilejava -jar isolation-manage.jar --spring.profiles.activeprod --server.port8080生产环境的数据库密码通过启动参数或环境变量注入export DB_PASSWORDxxx java -jar isolation-manage.jar --spring.profiles.activeprod --spring.datasource.password$DB_PASSWORD6.3 安全基线接口防刷与SQL注入接口安全方面登录接口必须加验证码防暴力破解我用的Hutool的验证码工具生成图片验证码值存Redis并设置五分钟过期。隔离管理系统虽然面向内部但登录接口暴露在公网不设防等于敞开大门。另外代码中所有SQL都尽量用参数绑定#{xxx}避免字符串拼接SQL导致注入风险。MyBatis的$符号只在明确需要动态表名时才用其他一律禁止。7. 这次开发踩过的坑和最终的优化建议7.1 时间字段时区问题第一个坑来自Jackson处理LocalDateTime。默认配置下返回给前端的格式是 2024-01-01T10:00:00和前端期望的 2024-01-01 10:00:00 不一致导致页面上显示怪异。解决方式是配置application.ymlspring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时后端时间字段统一用LocalDateTime不要混用Date和LocalDateTime不然序列化和时区处理会乱成一锅粥。这种细节初看不值钱生产上一旦出问题排查成本高得吓人。7.2 状态变更缺乏统一入口导致的脏数据开发初期我允许页面直接调update接口改isolation_person.status结果出现一个尬事某隔离人员还没确认入住就被误操作改成已解除。后来我明确立规矩所有状态流转必须走Service层的专用方法禁止Controller直接操作状态字段。结构化设计的价值在数据不一致的时候才会真正显现。7.3 MyBatis查询慢的排查思路系统上线初期统计报表接口偶尔会慢。定位发现是统计SQL里DISTINCT加GROUP BY在数据量大时走了全表扫描。我处理了两步一是把report_date和person_id的组合索引补齐二是在统计量大的时候把预聚合结果缓存到Redis设置5分钟过期。实测接口响应从2秒压到200毫秒以内。对于管理端报表这种允许一定程度延迟一致性的取舍在企业里是完全可行的。7.4 后续可以扩展的方向系统底层把人员和健康记录分离设计后续如果要做隔离点管理只需要加一张isolation_point表把 building 和 person 挂到点上基本不用改核心表如果要支持消息推送可以在健康记录异常后接入消息队列推送短信或小程序通知。MyBatis的mapper层已经留好了扩展位置加功能主要是增量开发不是推倒重来。8. 做这类管理系统我最后想强调的两件事第一件别把业务系统的核心价值搞成技术炫技。疫情隔离管理系统真正重要的是数据准、流程顺、权限严、能落地。SpringBoot、Vue、MyBatis、MySQL每样都是久经考验的成熟组件用它们的核心能力比追求新框架新中间件更靠谱。第二件交付前一定要把状态流转和权限边界测试透。这类系统的用户是医护和管理者他们的操作容错度极低——如果把已解除的人员重新流转成在隔后面所有统计都会出错。测试用例里必须覆盖异常状态流转的负面场景未入住人员不能上报健康、已解除人员不能修改状态、非管理员不能访问物资模块。最后分享一个实际运维心得这类管理系统上线后最受欢迎的功能永远是那个一键导Excel和首页统计大屏。开发时别觉得导出报表技术含量低就轻视管理者每天打开系统第一眼看到的就是那些数字这恰恰是整个项目的门面。数据同步准确、统计口径一致、页面打开够快做好了项目就成了。
SpringBoot+Vue+MyBatis+MySQL企业级疫情隔离管理系统完整实践
接手这个项目的时候我其实挺有感触的。疫情隔离管理这类系统看着是常规的信息化建设但真正做起来才发现SpringBoot Vue MyBatis MySQL这套技术栈在企业级场景下踩的坑全藏在人员流转、健康监测、数据上报、权限控制这些具体业务里。标题里企业级完整版这两个词意味着它不是一个教学Demo而是要考虑并发、权限、数据准确性和可维护性的交付物。这篇文章就围绕这套系统的完整实现过程从需求拆解到技术选型从后端骨架到数据库设计把关键代码和踩坑经验一起捋一遍希望对正在做同类管理系统的朋友有直接帮助。1. 疫情隔离管理系统的业务边界先搞清楚要管什么1.1 隔离点日常运转的真实痛点很多人一听到隔离管理系统第一反应是不就是做个登记表吗实际上隔离点的业务远比想象中复杂。一个标准隔离点每天要处理这几类高频事务新 arrival 人员登记入住、每日体温与症状上报、核酸结果回填、隔离期满转出、异常人员转诊、医护排班与任务分派以及防护服、口罩、消毒液等物资的出入库。这里面的核心难点在于状态流转。隔离人员不是静态数据他的状态会经历待入住、在隔、异常待转、已解除、已转出等阶段每个状态变更都可能触发后续动作。比如体温连续两次超过37.3℃系统要自动预警并把人员标记为异常同时生成待办事项推送给值班医护。这个过程如果仅仅靠一张表存数据业务逻辑会彻底失控。1.2 系统的核心业务闭环前期梳理需求时我把整个系统拆成了五个核心域业务域核心功能关键状态/字段人员管理入住登记、档案维护、状态流转姓名、证件号、入住时间、隔离类型健康监测每日体温/症状上报、核酸记录体温、症状描述、核酸结果、上报时间隔离记录隔离批次、解除/转出登记开始时间、预计结束时间、实际结束时间医护管理排班、任务分派、异常处理值班日期、负责楼栋、处理状态物资管理出入库、库存预警、领用登记物资名称、数量、领用人、领用时间这五个域一起构成闭环人员来了登记入住每天健康上报数据异常触发预警医护处理异常并记录转归解除隔离后回写入住档案。所有环节的数据最终汇总到统计报表供管理者查看隔离人数、健康率、物资消耗趋势。这个业务闭环就是整个系统的北极星后面所有技术设计——数据库表结构、接口划分、前端页面组织都必须围着它转。开发组内部我常说一句话先让业务闭环保得住再谈技术架构。业务流没理清楚就急着编码返工成本会是灾难级的。2. 技术选型分析为什么是SpringBoot Vue MyBatis MySQL这套组合2.1 选型逻辑企业级交付的权衡这套技术栈组合乍看平平无奇但放到企业级交付场景里它其实是经过了多层权衡的结果。我分别说说每个组件承担的角色。SpringBoot解决的是后端快速交付和生态整合问题。企业级项目最怕的是框架卡脖子SpringBoot的自动配置机制和starter生态能让团队把精力集中在业务代码上。比如内部接口用spring-boot-starter-web权限校验用spring-boot-starter-security或自定义拦截器数据库交互用mybatis-spring-boot-starter。版本升级也有成熟路径不像某些自研框架改一版死一片。MyBatis的选择可能有人会质疑为什么不直接用JPA这里说句实话复杂统计查询是这类系统的刚需而MyBatis对SQL的可控性、对多条件动态拼接的支持在报表类场景里有着明显优势。JPA虽然开发快但遇到那种跨三张表、六种筛选条件、还要分组统计的SQL调试成本远高于MyBatis里写一条provider动态SQL。尤其隔离管理系统的数据统计维度多按日期、按楼栋、按状态、按性别MyBatis这种半ORM模型正好卡在了开发效率和SQL可控性的最佳平衡点上。2.2 前端和后端的分工边界Vue的选择基本是当下企业级中后台的默认答案。前后端分离的结构下Vue负责页面交互、状态管理、路由控制后端只关心业务逻辑和返回JSON。这套系统里权限控制是一个绕不开的点——管理员、医护、隔离人员三种角色的操作边界完全不同前端利用 Vue Router 的导航守卫做路由级拦截后端再用 JWT 做接口级校验双重保障。MySQL在这个系统里承担的是数据准确性的责任。虽然隔离管理系统的数据量不大一个隔离点同时在线几百人算多的了但事务的可靠性是硬要求。比如物资出库时既要扣减库存又要写领用记录这两个操作必须保证要么都成功要么都失败MySQL的InnoDB事务在这里就是基础设施。加上MySQL本身的运维生态成熟中小型团队都能轻松维护。2.3 为什么不选微服务 / 为什么不用NoSQL开头提到企业级有的朋友可能觉得企业级微服务。这个认知需要纠正。我在需求评审时说过微服务的复杂度必须由业务复杂度来买单隔离管理系统这种单体就能跑得非常好的业务强行上微服务光服务间调用、链路追踪、分布式事务就能把团队拖垮。数据存储层面有人建议用Redis缓存人员信息。这个可以做但要分场景高频读取的基础数据比如楼栋列表、物资分类可以加缓存人员健康记录这种强一致性数据绝不能先写缓存再同步数据库这属于自找麻烦。MySQL在万级数据量下的表现完全够用垂直优化一下索引就足够了。3. 后端核心模块的实现思路与代码骨架3.1 先搭好地基统一响应与全局异常处理企业级系统最怕接口返回格式五花八门。开发初期我强制定了一条规矩所有接口必须走统一响应体。这个规范越早定越好不然后端写一个样前端对接的时候能吵起来。统一响应体我简单展示一下Data public class ResultT { private Integer code; private String message; private T data; private Long timestamp; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); result.setTimestamp(System.currentTimeMillis()); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); result.setTimestamp(System.currentTimeMillis()); return result; } }配套的全局异常处理用RestControllerAdvice实现拦截BusinessException、参数校验异常、数据库异常统一转成上述格式。这个地基搭好之后前端可以用一个统一的响应拦截器处理所有接口的 code、message、data不用每个接口单独判断。成本不高但后期维护舒适度提升巨大。3.2 隔离人员全生命周期管理状态机设计隔离人员是系统的核心主体我的设计思路是把他抽象成一条状态流待入住 - 在隔 - 解除/转出中间穿插异常这一特殊状态。状态流转必须走统一入口避免业务代码里散落着一堆直接改status字段的野路子。先设计一个枚举类public enum IsolationStatus { PENDING(0, 待入住), IN_ISOLATION(1, 在隔), ABNORMAL(2, 异常待处理), RELEASED(3, 已解除), TRANSFERRED(4, 已转出); private final int code; private final String desc; IsolationStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态流转逻辑我放在Service层统一处理——比如confirmArrival()确认入住、reportAbnormal()标记异常、completeIsolation()解除隔离。这样做的最大好处是业务规则集中比如异常状态的人员不允许直接解除隔离必须转出或经医护确认这条规则写在Service里任何入口调用都会经过校验。3.3 健康监测与预警定时任务 触发器思维健康上报是每天的高频操作隔离人员或者代填的医护每天上报体温和症状。这里的核心不是存数据而是趋势判断。我定义了两个预警维度单次异常体温大于37.3℃立即标黄连续异常同一人员连续两次上报体温大于37.3℃自动转异常待处理状态并生成待办连续异常的判断在SQL层面就好处理写一个查询最近两条记录的方法select idselectLastTwoHealthRecords resultTypeHealthRecord SELECT * FROM health_record WHERE person_id #{personId} ORDER BY report_date DESC, report_time DESC LIMIT 2 /select拿到后逐条比较连续两次超标就触发预警。这类规则如果做复杂了可以引入规则引擎但当前规模下Java代码里一段if判断就是最清晰高效的实现杀鸡不用牛刀。3.4 MyBatis动态SQL在复杂统计查询中的应用这套系统里最有技术含量的一段SQL是综合统计报表要按日期、楼栋、状态维度统计隔离人数和健康情况。多条件组合查询是MyBatis的强项我这里用where配合if标签做动态拼接select idselectStatsList resultTypemap SELECT DATE_FORMAT(hr.report_date, %Y-%m-%d) AS stat_date, b.building_name AS building_name, COUNT(DISTINCT hr.person_id) AS total_people, SUM(CASE WHEN hr.temperature 37.3 THEN 1 ELSE 0 END) AS abnormal_count FROM health_record hr LEFT JOIN isolation_person p ON hr.person_id p.id LEFT JOIN building b ON p.building_id b.id where if teststartDate ! null and startDate ! AND hr.report_date gt; #{startDate} /if if testendDate ! null and endDate ! AND hr.report_date lt; #{endDate} /if if testbuildingId ! null AND p.building_id #{buildingId} /if if teststatusCode ! null AND p.status #{statusCode} /if /where GROUP BY stat_date, b.building_name ORDER BY stat_date DESC /select动态SQL最大的价值在于查询条件可组合页面勾选什么筛选条件就拼接什么不需要为每种组合单独写一条SQL。但注意测试时必须把每种组合都跑一遍否则容易出现某个条件漏拼导致的统计偏差。3.5 权限控制JWT 拦截器的轻量方案企业级系统的权限控制要分层。后端我的做法是JWT认证 拦截器鉴权。登录接口校验账号密码后签发tokentoken里携带用户id和角色code拦截器从请求头摘出token并校验角色public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); } try { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(roleCode, claims.get(roleCode)); return true; } catch (Exception e) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\登录状态已失效\}); return false; } } }角色接口级校验我用RequireRole(ADMIN)这类自定义注解 AOP去做。比如物资管理模块只允许管理员操作隔离人员只能查看自己的健康记录和隔离信息。这套轻量方案在企业级场景里够用且好维护比引入Spring Security的全量配置更直观适合内部管理系统的权限复杂度。4. 数据库设计隔离管理场景下的表结构规划与索引优化4.1 核心表结构概览数据库设计我遵循按业务域分表、按查询场景建索引的原则。核心表包括isolation_person隔离人员、health_record健康记录、isolation_record隔离记录、building楼栋、nurse_task医护任务、material_stock物资库存、material_log物资流水。以isolation_person为例关键字段设计CREATE TABLE isolation_person ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, name varchar(50) NOT NULL COMMENT 姓名, id_card varchar(18) NOT NULL COMMENT 证件号, gender tinyint DEFAULT 0 COMMENT 性别0未知 1男 2女, phone varchar(20) DEFAULT NULL COMMENT 联系电话, building_id bigint DEFAULT NULL COMMENT 楼栋id, room_no varchar(20) DEFAULT NULL COMMENT 房间号, status tinyint DEFAULT 0 COMMENT 状态0待入住 1在隔 2异常 3解除 4转出, isolation_type tinyint DEFAULT NULL COMMENT 隔离类型1密接 2次密接 3入境 4其他, arrival_time datetime DEFAULT NULL COMMENT 入住时间, expect_release_time datetime DEFAULT NULL COMMENT 预计解除时间, actual_release_time datetime DEFAULT NULL COMMENT 实际解除时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_id_card (id_card), KEY idx_status (status), KEY idx_building_id (building_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT隔离人员表;几个设计要点值得说一下证件号唯一约束是硬性要求一个人同一时间不能重复隔离。所以id_card建了唯一索引后续重复登记直接报错应用层再给出友好提示。状态字段建议用数字枚举不要直接存中文。数据库层面数字更快、占用空间更小查询时的中文含义映射放到Java枚举里去做。时间字段全部用datetime避免用varchar。真实项目里我见过把时间存成字符串的表后来做日期范围统计时全是坑索引也白加了血的教训。4.2 高频查询与索引策略隔离点的高频查询几乎都围绕今天的健康上报名单和当前在隔人员列表展开。我给health_record表建了一个组合索引ALTER TABLE health_record ADD INDEX idx_person_date (person_id, report_date);这个索引最典型的查询是查某个人某一天的记录两条查询条件正好命中复合索引前缀效率极高。如果哪天系统数据量涨到百万级还能在这个基础上配合分区表按月份做分区不过现有规模完全没必要。4.3 一对多关系查询的N1问题隔离人员查健康记录天然是一对多查询。如果代码写法是先查人再循环查记录当列表灌满几百人时数据库要被查几百次性能直接雪崩。MyBatis里我利用collection做了嵌套结果映射一次性联表查出人员和当天记录resultMap idIsolationPersonWithHealthMap typeIsolationPerson id propertyid columnid/ result propertyname columnname/ collection propertyhealthRecords ofTypeHealthRecord id propertyid columnhr_id/ result propertytemperature columntemperature/ result propertyreportTime columnreport_time/ /collection /resultMap select idselectPersonWithTodayHealth resultMapIsolationPersonWithHealthMap SELECT p.id, p.name, hr.id AS hr_id, hr.temperature, hr.report_time FROM isolation_person p LEFT JOIN health_record hr ON p.id hr.person_id AND hr.report_date #{today} WHERE p.status 1 /select这个技巧在MyBatis里很常见但新手容易踩坑collection 映射时如果关联字段为空记得用LEFT JOIN并允许null否则查出来的列表会比实际少人。这个细节在测试不多的时候最容易漏掉。5. 前端工程化与关键交互细节5.1 Vue项目结构与动态路由前端用Vue 3 Vite Element Plus Vue Router Pinia标准的后台管理模板。项目目录按业务分开views 下保持和后端接口一一对应的组织方式src/ ├── api/ # 接口请求封装 │ ├── person.js │ ├── health.js │ └── stats.js ├── views/ │ ├── person/ # 人员管理页面 │ ├── health/ # 健康监测页面 │ ├── building/ # 楼栋管理 │ └── material/ # 物资管理 ├── router/ │ └── index.js # 路由配置 └── store/ # Pinia状态管理权限控制方面我在路由配置里给每个页面添加 meta 字段标记角色权限前端路由守卫判断当前登录用户的角色是否有权访问{ path: /material, component: Layout, meta: { roles: [ADMIN] }, children: [ { path: stock, component: () import(/views/material/stock.vue), meta: { title: 库存管理, roles: [ADMIN] } } ] }5.2 axios封装与接口对接细节企业级项目里接口请求不能裸调。我封装了一个request工具统一挂上JWT token、统一解析Result响应体、统一处理401跳登录、统一展示错误信息。import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 15000 }) 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) { return res.data } if (res.code 401) { localStorage.removeItem(token) router.push(/login) return Promise.reject(new Error(res.message)) } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(error.message || 请求失败) return Promise.reject(error) } )这里有个重要细节axios拦截器里统一把res.data解出来页面里request.get(/person/list)直接拿到的就是数据体不需要每页再写一次res.data.data的嵌套判空。这个约定全组统一能省下大量冗余代码。5.3 统计图表与数据可视化管理端大屏需要展示隔离人数趋势、各楼栋健康状态、物资库存水位。图表我用的ECharts封装成通用组件。需要注意的点组件卸载时记得销毁图表实例否则页面频繁切换会有内存泄漏和渲染错乱。一个简单做法是在onUnmounted里调用chart.dispose()。统计接口返回的数据结构要和前端图表组件对齐。比如折线图需要{ xAxisData: [01-01,01-02], seriesData: [20, 30] }这个结构在后端组装好再返回前端只负责渲染避免前端去重写一堆数组处理方法。6. 部署上线与企业级安全细节6.1 前后端分离部署配置项目交付时前后端分离部署我在生产环境给出一套标准拓扑后端SpringBoot打成jar包运行在8080端口前端Vue打包后的静态资源由Nginx托管Nginx再把/api前缀的请求反向代理到后端。Nginx配置是这样的server { listen 80; server_name 192.168.1.100; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }try_files那行必须加否则 Vue 路由在 history 模式下前端页面刷新会出现404白屏问题。我遇到过不少同事在这个地方卡到怀疑人生。6.2 配置外置与环境隔离企业级交付最忌讳配置文件硬编码。application.yml里数据库密码、JWT密钥这些敏感信息千万别写在代码仓库里。我习惯用bootstrap.yml配合application-prod.yml做环境隔离部署时通过命令行指定profilejava -jar isolation-manage.jar --spring.profiles.activeprod --server.port8080生产环境的数据库密码通过启动参数或环境变量注入export DB_PASSWORDxxx java -jar isolation-manage.jar --spring.profiles.activeprod --spring.datasource.password$DB_PASSWORD6.3 安全基线接口防刷与SQL注入接口安全方面登录接口必须加验证码防暴力破解我用的Hutool的验证码工具生成图片验证码值存Redis并设置五分钟过期。隔离管理系统虽然面向内部但登录接口暴露在公网不设防等于敞开大门。另外代码中所有SQL都尽量用参数绑定#{xxx}避免字符串拼接SQL导致注入风险。MyBatis的$符号只在明确需要动态表名时才用其他一律禁止。7. 这次开发踩过的坑和最终的优化建议7.1 时间字段时区问题第一个坑来自Jackson处理LocalDateTime。默认配置下返回给前端的格式是 2024-01-01T10:00:00和前端期望的 2024-01-01 10:00:00 不一致导致页面上显示怪异。解决方式是配置application.ymlspring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时后端时间字段统一用LocalDateTime不要混用Date和LocalDateTime不然序列化和时区处理会乱成一锅粥。这种细节初看不值钱生产上一旦出问题排查成本高得吓人。7.2 状态变更缺乏统一入口导致的脏数据开发初期我允许页面直接调update接口改isolation_person.status结果出现一个尬事某隔离人员还没确认入住就被误操作改成已解除。后来我明确立规矩所有状态流转必须走Service层的专用方法禁止Controller直接操作状态字段。结构化设计的价值在数据不一致的时候才会真正显现。7.3 MyBatis查询慢的排查思路系统上线初期统计报表接口偶尔会慢。定位发现是统计SQL里DISTINCT加GROUP BY在数据量大时走了全表扫描。我处理了两步一是把report_date和person_id的组合索引补齐二是在统计量大的时候把预聚合结果缓存到Redis设置5分钟过期。实测接口响应从2秒压到200毫秒以内。对于管理端报表这种允许一定程度延迟一致性的取舍在企业里是完全可行的。7.4 后续可以扩展的方向系统底层把人员和健康记录分离设计后续如果要做隔离点管理只需要加一张isolation_point表把 building 和 person 挂到点上基本不用改核心表如果要支持消息推送可以在健康记录异常后接入消息队列推送短信或小程序通知。MyBatis的mapper层已经留好了扩展位置加功能主要是增量开发不是推倒重来。8. 做这类管理系统我最后想强调的两件事第一件别把业务系统的核心价值搞成技术炫技。疫情隔离管理系统真正重要的是数据准、流程顺、权限严、能落地。SpringBoot、Vue、MyBatis、MySQL每样都是久经考验的成熟组件用它们的核心能力比追求新框架新中间件更靠谱。第二件交付前一定要把状态流转和权限边界测试透。这类系统的用户是医护和管理者他们的操作容错度极低——如果把已解除的人员重新流转成在隔后面所有统计都会出错。测试用例里必须覆盖异常状态流转的负面场景未入住人员不能上报健康、已解除人员不能修改状态、非管理员不能访问物资模块。最后分享一个实际运维心得这类管理系统上线后最受欢迎的功能永远是那个一键导Excel和首页统计大屏。开发时别觉得导出报表技术含量低就轻视管理者每天打开系统第一眼看到的就是那些数字这恰恰是整个项目的门面。数据同步准确、统计口径一致、页面打开够快做好了项目就成了。
